为什么在使用实体框架时要重新启动DbContext ?

Question

我不知道是否有更好的方法来使用DbContext，因为不建议在使用WCF时将其设置为静态。因此，每次我们想要访问数据库时，我们都会创建它。

知道使用实体框架的所有优点，一些变得无用，因为我们每次都要重新创建DbContext;而且由于要考虑创建大型实体模型的过程，因此更多可能会导致开销。

你的意见是什么?

Answer 1

管理生命周期

你是正确的，DbContext的单个静态实例是通常不推荐:

ObjectContext使用得越多，它就越大。这是因为它持有对它曾经拥有的所有实体的引用知道，基本上是你查询，添加或附加的任何内容。因此，您应该重新考虑无限期地共享同一个ObjectContext。

这些注释直接适用于DbContext，因为它包装了ObjectContext以暴露"简化和更直观的api"。[见文档]

---

建设成本

创建上下文的开销相对较低:

现实是这个成本实际上是相当低的，因为大多数情况下只是通过引用从全局缓存复制元数据到新的ObjectContext中。总的来说，我认为这个费用不值得担心。

处理短时间上下文的常用方法是将其封装在using块中:

using(DbContext context = new SomeDbContext())
{
    // Do work with context
}

为了方便测试，您可能想让您的DbContext实现一些IDbContext接口，并创建一个工厂类ContextFactory<T> where T : IDbContext来实例化上下文。

这允许您轻松地将任何IDbContext交换到您的代码中(例如:对象模拟的内存上下文)

---

• MSDN:如何决定ObjectContext的生存期
• StackOverflow:在LINQ中实例化上下文

Answer 2

web开发的最佳实践似乎是"每个web请求一个上下文"，请参阅适当的会话/DbContext生命周期管理，当与WCF一起工作时，可以转换为每个操作一个上下文(即每个WCF方法调用一个上下文)。

有不同的方法可以实现这一点，但有一个解决方案，可能不推荐出于不同的原因，是创建上下文的一个新实例，并将其传递给您的业务类的构造函数:

public void WCFMethod()
{
  using (DBContext db = new DBContext())
  {
    BusinessLogic logic = new BusinessLogic(db);
    logic.DoWork();
  }
}