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

时间:2012-03-27 09:00:48

标签: c# asp.net-mvc entity-framework idisposable

我在很多例子中看到 MVC 存储库模式,工作单元 EF ,例如here,接口和类都实现IDisposable接口。我想这个接口只暴露了方法Dispose(),有2个重载。

然而,在高级程序员的许多其他例子中,我没有看到这样的实现。实际上对我而言,每个Web请求都会解散一个组件,因为每个请求都有一个全新的控制器实例。

或者即使不是这种情况,我想通过使用依赖注入框架,例如 Ninject ,我们将所有这些处理任务委托给框架。

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

有人可能会指出我正确的方向吗?

更新

可以在具有服务存储库图层的分层应用程序中查看上下文的自动处理。假设我们从两个组件返回IQueryable<T>个对象,如果我们尝试从控制器填充对象,通过迭代其项或调用ToList()方法,我们得到一个运行时错误说上下文无法访问(已关闭)

3 个答案:

答案 0 :(得分:3)

常见模式是在每个Controller中都有一个Repository实例,并将Disposal链接到Controller的Dispose()。

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

  

然而,在高级程序员的许多其他例子中,我没有看到这样的实现。

有几种可能性:

  • 是演示代码,错误和资源处理省略。
  • 模式在非显而易见的地方(基类)实施

指出一个具体的例子,我们可以找到答案。

答案 1 :(得分:2)

通常在大多数示例中,您可以使用EF在interner上找到关于Repository模式的上下文有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

答案 2 :(得分:2)

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