如果这个问题已经有答案了，那么对不起，但是如果您不使用 IOC 容器，如何保证每个请求只有一个 Entity Framework DbContext？（目前我找到的答案都是关于 IOC 容器的解决方案。）
看起来大部分解决方案都会钩入 HttpContext.Current.Items 字典，但是当请求完成时，如何确保 DbContext 被清除？（或者使用 EF DbContext 时是否不必要清除？）
编辑
我目前在我的控制器中实例化和清除了 DbContext，但是我还有一些在 ActionFilters 和 MembershipProvider 中独立实例化的 DbContext（我刚刚还发现，还有一些验证器）。因此，我认为将我的 DbContext 的实例化和存储集中化可能是个好主意，以减少开销。
虽然这不是一个新问题，但我仍然要发布我的答案，因为我相信可能有人会发现它有用。
像许多其他人一样，我按照接受的答案中提到的步骤进行操作。耶，它起作用了。然而，这里有一个问题：
BeginRequest()和EndRequest()方法每次发出请求时都会触发，但不仅限于aspx页面，还包括所有静态内容！也就是说，如果您使用上面提到的代码，并且在您的页面上有30个图像，您将重新实例化您的数据库上下文30次！
解决办法是使用一个包装类来检索上下文，类似于以下内容：
internal static class ContextPerRequest
{
internal static DB1Entities Current
{
get
{
if (!HttpContext.Current.Items.Contains("myContext"))
{
HttpContext.Current.Items.Add("myContext", new DB1Entities());
}
return HttpContext.Current.Items["myContext"] as DB1Entities;
}
}
}
然后对其进行销毁处理
protected void Application_EndRequest(object sender, EventArgs e)
{
var entityContext = HttpContext.Current.Items["myContext"] as DB1Entities;
if (entityContext != null)
entityContext.Dispose();
}
我会使用BeginRequest/EndRequest方法，这有助于确保在请求结束时正确处理上下文。
protected virtual void Application_BeginRequest()
{
HttpContext.Current.Items["_EntityContext"] = new EntityContext();
}
protected virtual void Application_EndRequest()
{
var entityContext = HttpContext.Current.Items["_EntityContext"] as EntityContext;
if (entityContext != null)
entityContext.Dispose();
}
在你的EntityContext类中...
public class EntityContext
{
public static EntityContext Current
{
get { return HttpContext.Current.Items["_EntityContext"] as EntityContext; }
}
}
Application_BeginRequest事件，将DbContext注入到当前的HttpContext中，在Application_EndRequest中从HttpContext获取并处理。在这之间（几乎包括所有步骤），都可以从当前HttpContext中获取DbContext并使用它。同时需要注意，确实需要将其Dispose。另外，是否有某些原因导致您不使用已经为您做好这些工作的DI框架呢？_service 应该在测试项目中声明为 IService 并实现为 ITestService，以便轻松进行测试。总之，说了这么多，仍然由你决定。 :) - RPM1984对于Chad Moran所提供的答案，我有一个小补充。它受到了Walther Notes的启发。为了避免为静态内容进行上下文初始化，我们应该检查当前路由处理程序（以下示例仅适用于MVC）：
protected virtual void Application_BeginRequest()
{
var routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(this.Context));
if (routeData != null && routeData.RouteHandler is MvcRouteHandler)
{
HttpContext.Current.Items["_EntityContext"] = new EntityContext();
}
}
Application_PreRequestHandlerExecute，则可以仅检查 this.Context.Handler is MvcHandler，因为在处理管道的此时点上它将被设置。 - Jeff Camera如果您在控制器中实现了IDisposable，并在disposing方法中dispose上下文，并在控制器构造函数中实例化新上下文，则每个请求实例化控制器时应该是安全的。
但我不明白，为什么要这样做呢？...
您应该使用依赖注入（DI），或制作一个带有一个静态上下文实例的上下文工厂。如果您不使用一个实例（为每个请求创建一个实例），则在某些时候会遇到问题。未处理的上下文的问题在于EF会缓存上下文中的数据，如果另一个上下文实例更改已经在另一个上下文中缓存的DB中的内容，则存在不一致状态。在DI变得如此流行之前，我曾经在应用程序中的某个地方有一个静态上下文实例，这比让每个请求都创建自己的上下文快得多且更安全，但是需要实现状态检查代码以确保上下文与数据库的连接正常...解决此问题有更好的解决方案，其中最好的是使用一些DI框架。我建议使用Ninject与MVCTurbine结合使用，它易于设置，可以通过NuGet添加。
这里的悬崖是状态不一致。如果您的应用程序将有多个用户，并且他们有可能同时更改数据，那么如果您保留单个上下文，则可能会遇到数据完整性问题。