asp.net-mvc-3 - 处理 DbContext 后的问题

Question

我最近对我的 MVC3 应用程序进行了更改，以尝试正确处理 DbContext对象 [1]。这在开发中效果很好，但是一旦应用程序被推送到我的生产服务器，我开始间歇性地收到一些有趣的异常，这些异常会持续到 AppPool 被回收。异常可以追溯到我自定义中的代码 AuthorizeAttribute看起来像:

System.InvalidOperationException: The 'Username' property on 'User' could not be set to a 'Int32' value. You must set this property to a non-null value of type 'String'.

System.InvalidOperationException: The 'Code' property on 'Right' could not be set to a 'String' value. You must set this property to a non-null value of type 'Int32'. 

(数据库架构如下所示:用户:[Guid, String, ...]，权限:[Guid, Int32, ...])

就好像一些“电线正在交叉”，并且应用程序正在混淆来自数据库的结果:试图实现 Right结果为 User反之亦然。

管理处置 DbContext ，我放入代码以将其存储在每个 Controller 级别。处置 Controller 时，我处置 DbContext以及。我知道它很老套，但是 AuthorizeAttribute通过 filterContext.Controller 使用相同的上下文.

处理 DbContext 的对象生命周期有什么问题吗？在这个庄园？关于为什么我得到上述纵横交错的异常(exception)，是否有任何合乎逻辑的解释？

[1] 虽然我明白没有必要处理 DbContext对象，我最近遇到了一些消息来源，他们说无论如何这是最佳实践。

编辑(根据@MikeSW 的评论)
AuthorizeAttribute的属性代表 DbContext正在 OnAuthorization中设置方法，当 AuthorizationContext在范围内。此属性随后在 AuthorizeCore 中使用。方法。

Answer 1

你真的需要处理上下文吗？
根据 this post由与 Microsoft ADO.NET Entity Framework 团队保持联系的 Jon Gallant 撰写:

Do I always have to call Dispose() on my DbContext objects? Nope

Before I talked with the devs on the EF team my answer was always a resounding “of course!”. But it’s not true with DbContext. You don’t need to be religious about calling Dispose on your DbContext objects. Even though it does implement IDisposable, it only implements it so you can call Dispose as a safeguard in some special cases. By default DbContext automatically manages the connection for you.