每组操作都可重用的ObjectContext或新的ObjectContext？

Question

我是实体框架的新手，并且在业余时间开始使用它。 我的主要问题之一是关于如何处理ObjectContexts。

这些通常是首选/推荐的：

这个

public class DataAccess{

    MyDbContext m_Context;

    public DataAccess(){
        m_Context = new MyDbContext();        
    }

    public IEnumerable<SomeItem> GetSomeItems(){
        return m_Context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        m_Context.DeleteObject(item);
        m_Context.SaveChanges();
    }
}

或这个？

public class DataAccess{

    public DataAccess(){ }

    public IEnumerable<SomeItem> GetSomeItems(){
        MyDbContext context = new DbContext();
        return context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        MyDbContext context = new DbContext();
        context.DeleteObject(item);
        context.SaveChanges();
    }
}

Answer 1

ObjectContext应该是“工作单元”。

本质上，这意味着对于每个“操作”（例如，每个网页请求），都应该有一个新的ObjectContext实例。 在该操作中，应重新使用相同的ObjectContext。

当您考虑时，这是有道理的，因为事务和变更提交都与ObjectContext实例相关。

如果您不是在编写Web应用程序，而是在编写WPF或Windows Forms应用程序，那么它将变得更加复杂，因为您没有Web页面加载所提供的严格的“请求”范围，但您明白了。

PS：在您的任何一个示例中，ObjectContext的生存期将是全局的或短暂的。 在两种情况下，它都不应存在于DataAccess类中-应该将其作为依赖项传递

Answer 2

如果您为长时间运行的进程保留了相同的上下文，则对它运行很多查询 ，则linq-to-sql（我没有针对实体的linq进行测试，但我想这是相同的问题）变得非常慢（每秒查询1次）经过大约1000次简单查询）。 定期更新上下文可以解决此问题，并且不会花费太多。

发生的情况是上下文会跟踪您对它所做的每个查询，因此，如果不进行某种方式的重置，它会变得很胖...另一个问题是它占用的内存。

因此，这主要取决于应用程序的工作方式，是否定期新建DataAccess实例或是否始终保持相同。 希望这可以帮助。

斯特凡

Answer 3

简要说明一下-这两个代码段的基本问题大致相同。 这是我一直在研究的内容，因为您不想同时打开和关闭上下文（请参见第二个示例），因此不确定您是否可以信任Microsoft为您正确处理上下文。

我要做的一件事是创建一个公共基类，该基类可以懒惰地加载Context并实现基类的析构函数来处理事物。 这对于MVC框架之类的东西来说效果很好，但是不幸地导致了必须将上下文传递到各个层以便业务对象可以共享调用的问题。

最后，我使用Ninject进行了一些操作，将这种依赖关系注入到每个层中，并使其跟踪使用情况

Answer 4

尽管我不总是总是创建复杂对象，但我每次都需要创建复杂对象-我也发现，Linq to Sql中的DataContexts和EF中的ObjectContexts最好在需要时创建。

这两种方法都基于您运行它们的模型执行了大量的静态初始化，该模型被缓存供后续调用使用，因此您会发现上下文的初始启动将比所有后续实例更长。

您面临的最大障碍是，一旦您从上下文中获得实体，就不能简单地将其传递回另一个实体以执行更新操作或重新添加相关实体。在EF中，您可以重新附加实体适应新的环境。 在L2S中，这个过程几乎是不可能的。