2

我最近开始使用受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. anew DbContext在每种方法中。
  2. 每个new DbContext对象（类成员）。
  3. 注射DbContext.

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

其他几个问题：

  • 如果 DbContext 保留为类成员，我的 repo 是否应该实现 IDisposable？
  • 有没有比上面更好的方法来处理 DbContext 的处置？
4

2 回答 2

2

我总是会使用InRequestScope. 提供依赖注入的所有好处。Ninject 还将在循环结束时释放 DBContext，因为 DBContext 实现了 IDisposable。看到这个线程

如果您使用 DI，那么您的其他两个问题将变得无关紧要。

于 2013-08-08T06:42:57.700 回答
0

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

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

附带说明一下，如果您的应用程序没有大量查询，则Using在 DbContext 周围使用块将被认为是理想的（因为这会为您处理处置），但同样，运行时和内存使用结果将是微不足道。

于 2013-08-08T04:03:41.520 回答