ASP.NET MVC 中的每个请求一个 DbContext（没有 IOC 容器）

Question

抱歉，如果这个问题已经得到解答，但是如果您不使用 IOC 容器，如何保证每个请求一个实体框架 DbContext？ （到目前为止，我遇到的答案都是关于 IOC 容器解决方案的。）

似乎大多数解决方案都与HttpContext.Current.Items 字典挂钩，但如何保证在请求完成后处理 DbContext？ （或者使用 EF DbContext 处理不是绝对必要的吗？）

编辑

我目前正在我的控制器中实例化和处理我的 DbContext，但我在 ActionFilters 和我的 MembershipProvider 中也有几个单独的 DbContext 实例（我刚刚注意到，还有几个验证器）。因此，我认为集中实例化和存储我的 DbContext 以减少开销可能是个好主意。

Answer 1

我知道这不是最近的问题，但无论如何我都会发布我的答案，因为我相信有人可能会觉得它很有用。

可能与许多其他人一样，我遵循了已接受答案中提到的步骤。是的，它有效。 但是，有一个问题：

方法 BeginRequest() 和 EndRequest() 每次发出请求时触发，但不仅适用于 aspx 页面，还适用于所有静态内容！也就是说，如果您使用上面提到的代码并且您的页面上有 30 张图片，那么您将重新实例化您的 dbcontext 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();
}

此修改可确保您在每个请求中仅在需要时实例化和处置上下文一次。选定的答案每次都会实例化上下文。

注意： DB1Entities 派生自 DbContext（由 VS 生成）。你可能想用你的上下文名称来改变它；）

注意 2： 在此示例中，我只使用一个 dbcontext。如果您需要使用多个，则需要根据需要修改此代码。不要把它当作世界问题的最终解决方案，因为它肯定不是最终产品。它只是为了提供一个提示，如何以一种非常简单的方式实现它。

注意 3： 同样的方法也可以在不同的情况下使用，例如，当您想要共享 SqlConnection 的实例或任何其他... DbContext 对象，也不是实体框架。

Answer 2

我会使用 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; }
    }
}

Answer 3

一种方法是订阅 Application_BeginRequest 事件，将 DbContext 注入当前 HttpContext 并在 Application_EndRequest 从 HttpContext 中获取并处理。介于两者之间的任何东西（几乎是所有东西:-)）都可以从当前的 HttpContext 获取 DbContext 并使用它。而且，是的，你应该处理它。顺便说一句，你有什么理由不使用已经为你做这件事的 DI 框架以及其他有用的东西？

Answer 4

乍得莫兰回答的小补充。它的灵感来自瓦尔特笔记。为避免静态内容的上下文初始化，我们应该检查当前路由处理程序（此示例仅适用于 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();
  }
}

Answer 5

如果您在控制器中实现 IDisposable，并在 disposing 方法中释放上下文，并在控制器构造函数中实例化新上下文，那么您应该是安全的，因为控制器是为每个请求实例化的。 但是，我不明白，您为什么要这样做？ ... 您应该使用 DI，或者使用一个静态上下文实例创建一个上下文工厂。如果您不使用一个实例（您为每个请求创建一个），那么您在某些时候会遇到问题。未处理上下文的问题是 EF 在上下文中缓存数据，并且如果其他上下文实例更改了数据库中已经缓存在另一个上下文中的某些内容 - 您的状态不一致。在 DI 变得如此流行之前，我曾经在应用程序的某个地方有一个静态的上下文实例，这比让每个请求都创建自己的上下文要快得多，也更安全，但是你需要实现状态检查代码来确保上下文连接到db没问题...这个问题有很多更好的解决方案，最好是使用一些DI框架。我建议将 Ninject 与 MVCTurbine 结合使用，它易于设置，您可以通过 NuGet 进行添加。

Answer 6

这里的滑坡状态不一致。如果您的应用程序将有多个用户，并且他们有可能同时更改数据，那么如果您保留单个上下文，您可能会开始遇到数据完整性问题。