Question

MVC 3 + EF 4.1

我在两种方法中选择处理DbContext：

在Application_BeginRequest中实例化，将其放入 HttpContext.Current.Items并置于Application_EndRequest。
创建一次性UnitOfWork（DbContext的包装器）和使用using(var unitOfWork = new UnitOfWork()) { ... }

请分享您的经验：您更喜欢哪一个？每种方法的利弊是什么？

Answer 1

我建议您使用依赖注入框架。您可以根据请求注册DbContext

 container.RegisterType<MyDbContext>().InstancePerHttpRequest();

将其作为构造函数参数注入控制器。

public class MyController : Controller
{
    public MyController(MyDbContext myDbContext)
    {
         _myDbContext = myDbContext;
    }
}

如果注册类型实现IDisposable，那么DI框架将在请求结束时处理它。

第一种方法：使用ID框架要比手动实现它更清晰。此外，您的所有请求可能都不需要您的UoW。

第二种方法：控制器不应该知道如何构建你的UoW（DbContext）。目的不是减少组件之间的耦合。

Answer 2

我们目前使用通过服务定位器从存储库工厂实例化的UoW（工作单元）注入的存储库。 Unity通过这种方式控制着你的工作生涯。

您的具体实施方式将因您使用POCO，实体对象等而有所不同。

如果您要在控制器中使用多个对象集来确保只使用一个上下文，那么最终您需要UoW。这将使您的交易得到检查等。

如果你打算使用多个objectcontexts（即多个EDMX），你会想看看使用UoW和MSDTC ...但这可能比你想知道的要多。最后，重要的是确保您只是实例化控制器操作所需的内容（即上下文的一个实例）。我不认为我会使用Begin_Request，你可能甚至不需要每个请求的上下文。

Answer 3

不要将DbContext放在global.asax中！：