什么时候/如何在返回IQueryable时处理DbContext？

Question

我最近开始使用受http://www.codethinked.com/keep-your-iqueryable-in-check启发的IQueryable。所以我已经习惯在我的回购中这样做了：

public IEnumerable<POCO> GetById(int id)
{
   using (var ctx = new DbContext())
   {
      var query = from ...;
      return query.ToList();
   }
}

现在我正在这样做：

public IPageable<POCO> GetById(int id)
{
   var ctx = new DbContext()
   var query = from ...;
   return new Pageable(query);
}

但我想知道这是否是处理new DbContext()的最佳方法。 将DbContext作为班级成员

更好吗？

public class Repo
{
   private DbContext _ctx = new DbContext();
}

甚至注射它

public class Repo
{
   private DbContext _ctx;

   public Repo(DbContext ctx)
   {
      _ctx = ctx;
   }
}

有什么利弊：

1. 每个方法中new DbContext。
2. 每个对象new DbContext（类成员）。
3. 注入DbContext。

我正在使用Ninject，因此我可以使用.InRequestScope();（如果这会影响答案）

其他几个问题：

• 如果将DbContext保留为类，我的repo应该实现IDisposable 会员？
• 是否有更好的方法来处理DbContext然后上面的处理？

Answer 1

我总是会使用InRequestScope注入DBContext。提供依赖注入的所有好处。当DBContext实现IDisposable时，Ninject还会在循环结束时释放DBContext。见thread

如果你使用DI，你的另外两个问题就变得无关紧要了。

Answer 2

实体框架喜欢缓存。如果您经常更改应用程序并在浏览器中重新加载它，您可能会注意到第一次重新加载它时，需要几秒钟才能加载，但之后，页面几乎是瞬间完成的。这是因为MVC和EF正在缓存重复使用的常见查询，这使得您的应用程序在初始加载时间之后可以更快地使用。

因此，在创建DBContext时不会引起太大关注。是的，创造任何东西需要时间。但是，即使您刚刚创建了上下文的新实例，EF也会识别这些查询并快速加载它们。

另一方面，如果您的应用程序没有大量查询，那么在您的DbContext周围使用Using块将被认为是理想的（因为它会为您处理配置），但同样，运行时和内存使用结果可以忽略不计。