管理DbContext EF6

Question

我正在建立一个Webforms EF6数据库的第一个应用程序，不确定如何最好地管理DbContext。我看了很多教程和论坛帖子，但我仍然很确定。关于非常受欢迎的“按请求使用”，我还没有找到一种一次性保存父母和孩子的方法。我让它与下面的代码一起工作，但是我应该在哪里以及什么时候处理上下文呢？我可以使用这种方法吗？Kamyar shown here的per request方法会更好吗？

这是我现在得到的：

public static class ContextManager
{
    [ThreadStatic]
    private static MyContext current;

    public static MyContext MyCurrentContext
    {
        get{
        if (current == null)
            current = new MyContext();

        return current;
    }}
}

再加上

var context = ContextManager.MyCurrentContext;
.....
context.SaveChanges();

提前感谢您的帮助！

一个具体的例子是'UserProfile‘，它包含子对象作为属性，比如'DefaultInvoiceAddress’，它返回表中用户的默认发票地址和所有用户的地址。在我工作的上一个web应用程序中，当用户在配置文件中编辑此地址(例如街道变化)以及其他表中的其他配置文件信息时，EF会在一个请求中保存来自不同表的所有编辑信息(确保它们是附加的)。由于我不了解上下文管理，我不知道它是如何完成的，但我们总是为请求分配一个通用的当前上下文。

我遇到了this post by Rick Strahl，this one by Jordan van Gogh -业务对象/事务似乎是一个答案，但我不太理解如何实现它，也找不到一个示例。“每个HTTP请求的共享ObjectContext实例”与上面提到的Kamyar的答案相对应，综合考虑，它听起来是个不错的选择。我是否必须显式地处理上下文，如果是这样，何时/何地？有什么缺点吗？

Answer 1

馊主意。静态完全违背了最佳实践。没有两个用户会同时使用这个应用吗？唉哟。为了WebForms。

Per request是最佳选择。

Answer 2

EF数据库上下文对象是而不是，我重复一遍，不管你怎么管理它，都不是线程安全。跨线程共享数据库上下文可能会出现许多问题，因此，如上所述，最好的方法是在每个请求中使用它。

如果你不想跳到IoC/DI这一方面，一种非常简单的方法是，每当你需要数据库时，你只需在using块中实例化你的上下文，如下所示：

using(var db = new MyContext())
{
    // code reading from/writing to database
    ...
    ...
}

Answer 3

将单例模式与实体框架数据库上下文一起使用是一个设计缺陷，特别是当您使用并发环境时，因为您必须考虑到DbContext不是线程安全对象。