在MVC中使用实体框架时，是否有必要实现IDisposable

本文关键字：是否 IDisposable 实现 MVC 框架 实体 | 更新日期: 2023-09-27 18:29:10

我在许多关于MVC、Repository模式、工作单元和EF的示例中看到，例如，在这里，接口和类都实现了IDisposable接口。我猜这个接口只公开了带有2个重载的方法Dispose()。

然而，在资深程序员所做的许多其他例子中，我看不到这样的实现。事实上，在我看来，在每个web请求上都会忽略一个组件，这似乎很合乎逻辑，因为每个请求都会得到一个全新的控制器实例。

或者，即使不是这样，我想通过使用依赖注入框架，如Ninject，我们也会将所有这些处理任务委托给该框架。

在旧版本的EF或MVC框架中也可能需要实现IDisposable。

有人可以给我指正确的方向吗？

更新

上下文的自动处理可以在具有Service和Repository层的分层应用程序中看到。假设我们从两个组件返回IQueryable<T>对象，如果我们试图通过迭代其项或调用ToList()方法来从控制器填充对象，我们会得到一个运行时错误，表明上下文不可访问（关闭）

在MVC中使用实体框架时，是否有必要实现IDisposable

常见的模式是在每个控制器中都有一个Repository实例，并将Disposal链接到控制器的Dispose（）中。

所以我想说，这种模式通常是必需的。

然而，在资深程序员所做的许多其他例子中，我看不到这样的实现。

有几种可能性：

  • 它是Demo代码，省略了错误和资源处理
  • 该模式是在一个不明显的地方实现的（基类）

指出一个具体的例子，我们就能发现。

通常在interner上找到的关于使用EF的Repository模式的大多数示例中，Context都有Dispose方法。

现在您不需要严格地在Context上调用Dispose方法，但这可能是一个很好的做法，原因如下：

DataContext保存状态（例如，SqlConnection和指向已检索对象的指针）。一旦您释放了所有引用，GC最终会清理这些对象，但其中一些对象（例如，底层SqlConnection）可能包含您通常希望在完成后立即释放的资源，而不是依赖GC来清理

对于懒惰的人：您甚至可以将上下文包装在using语句中，当对象脱离使用自身的范围时，该语句将为您调用dispose

更多信息，请访问：

http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/thread/2625b105-2cff-45ad-ba29-abdd763f74fe/

在这里你还可以找到一个关于EF 中Repository模式的例子

http://www.codeproject.com/Tips/309753/Repository-Pattern-with-Entity-Framework-4-1-and-C

关于连接状态，EF应该非常擅长仅在需要时保持连接打开(http://msdn.microsoft.com/en-us/library/bb896325.aspx)。该链接还显示了如何更好地控制连接状态。

相关文章：