集中 CloudStorageAccount 和 TableServiceContext 实例

发布于 2025-01-01 12:43:29 字数 1874 浏览 0 评论 0 原文

在 ASP.NET MVC 3 Web 角色中,我意识到我已经编写了很多下面的代码:

var account = 
    CloudStorageAccount.Parse(
        RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
    );

var ctx = 
    account.CreateCloudTableClient().GetDataServiceContext();

因此,我决定将其集中到整个 ASP.NET MVC 应用程序中,并创建了以下具有静态属性的类

internal class WindowsAzureStorageContext {

    public static CloudStorageAccount StorageAccount { 

        get {
            return
                CloudStorageAccount.Parse(
                    RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
                );
        }
    }

    public static TableServiceContext TableServiceCtx { 
        get {

            return
                StorageAccount.CreateCloudTableClient().GetDataServiceContext();
        } 
    }
}

: ,我在我的控制器中使用它,如下所示:

public class HomeController : Controller {

    private readonly TableServiceContext ctx = 
        WindowsAzureStorageContext.TableServiceCtx;

    public ViewResult Index() {

        var model = ctx.CreateQuery<TaskEntity>(Constants.TASKS_TABLE).
            Where(x => x.PartitionKey == string.Empty);

        return View(model);
    }

    public ViewResult Create() {
        return View();
    }

    [ActionName("Create")]
    [HttpPost, ValidateAntiForgeryToken]
    public ViewResult Create_post(TaskEntity taskEntity) {

        ctx.AddObject(Constants.TASKS_TABLE, new TaskEntity(taskEntity.Task));
        ctx.SaveChangesWithRetries();

        return RedirectToAction("Index");
    }
}

我知道这不是一个单元测试友好的,我应该通过 DI 的接口来访问 TableServiceContext 实例,但是当我这样做时,我考虑使用这WindowsAzureStorageContext 类以及获取 TableServiceContext 类的实例。

这是一个好的做法吗?因为我在整个应用程序生命周期中使用相同的类,它会在任何时候伤害我吗?

有什么已知的模式可以做到这一点吗?

In an ASP.NET MVC 3 Web Role, I have realized that I have been writing the below code a lot:

var account = 
    CloudStorageAccount.Parse(
        RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
    );

var ctx = 
    account.CreateCloudTableClient().GetDataServiceContext();

So, I decided to Centralize this for the entire ASP.NET MVC application and I created the below class with static properties:

internal class WindowsAzureStorageContext {

    public static CloudStorageAccount StorageAccount { 

        get {
            return
                CloudStorageAccount.Parse(
                    RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
                );
        }
    }

    public static TableServiceContext TableServiceCtx { 
        get {

            return
                StorageAccount.CreateCloudTableClient().GetDataServiceContext();
        } 
    }
}

And, I am using this as below inside my controllers:

public class HomeController : Controller {

    private readonly TableServiceContext ctx = 
        WindowsAzureStorageContext.TableServiceCtx;

    public ViewResult Index() {

        var model = ctx.CreateQuery<TaskEntity>(Constants.TASKS_TABLE).
            Where(x => x.PartitionKey == string.Empty);

        return View(model);
    }

    public ViewResult Create() {
        return View();
    }

    [ActionName("Create")]
    [HttpPost, ValidateAntiForgeryToken]
    public ViewResult Create_post(TaskEntity taskEntity) {

        ctx.AddObject(Constants.TASKS_TABLE, new TaskEntity(taskEntity.Task));
        ctx.SaveChangesWithRetries();

        return RedirectToAction("Index");
    }
}

I know that this is not a unit test friendly and I should reach out that TableServiceContext instance through a interface by DI but when I do that, I consider using this WindowsAzureStorageContext class as well to get an instance of TableServiceContext class.

Is this a good practice? Would it hurt me in any point because I am using the same class for the entire application life-cycle?

Is there any know pattern to do this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

滥情空心 2025-01-08 12:43:29

我认为这样做没有任何问题。看起来是一个很好的干净的方法。我不知道有什么已知的模式可以做到这一点,但只是想昨天应该有。

I don't see any problem with doing that. Looks like a nice clean way to do it. I don't know of a known pattern to do this but was just thinking there should be yesterday.

铃予 2025-01-08 12:43:29

我认为您可以将存储库模式用于通用数据上下文,并在其之上使用通用接口。不确定它是否有帮助,但您可以参考我的博客 http://blogs.shaunxu.me/archive/2010/03/15/azure-ndash-part-5-ndash-repository-pattern-for-table-service.aspx

I think you can use repository pattern for a generic data context, with a generic interface on top of it. Not sure if it helps but you can refer my blog http://blogs.shaunxu.me/archive/2010/03/15/azure-ndash-part-5-ndash-repository-pattern-for-table-service.aspx

如此安好 2025-01-08 12:43:29

我不相信上下文实例之间存在任何共享状态。话虽如此,控制器执行的事务时间并不简单。你掌握上下文的时间越长,就越有可能发生冲突。我发现将冲突和重叠保持在最低限度的一种方法是保持加载/更改/保存周期尽可能短。

埃里克

I don't believe that there is any shared state between instances of the context. With that said, the transaction time for the controller to execute is non-trivial. The longer you hold onto the context, the more likely you are to get conflicts. I've found that one way to keep conflicts and overlaps to a minimum is to keep the load/change/save cycle as short as possible.

Erick

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文