避免用using包装DbContext【翻译】

   EF和EF Core 的DbContext类实现IDisposable接口。因此,很多最佳编程实践中都建议你将它们放在一个using()块中。不幸的是,至少在Web应用程序中,这样做通常不是一个好主意。
   我与许多从.NET Framework迁移到.NET Core和.NET 5的客户一起工作,其中一些客户在旧版应用程序中并没有使用依赖项注入,或者没有一直使用它。结果导致他们的DbContext类有大量的实例。这样做有很多问题,其中最重要的是它导致了紧耦合。
                  “在Web应用程序中,每个Web请求应该有且只有一个DbContext。”
   如果您遵循上述规则,则一切正常。否则可能会有很多麻烦。比如你会遇到这样的问题:如何跟踪实体,或被跟踪的实体在你认为应保存时并没有保存(稍后对此进行详细介绍)。尤其是如果使用异步代码,你可能会发现DbContext被释放的意外情况,这可能需要一些时间来解决。
                  “在ASP.NET或ASP.NET Core中,配置DbContext最理想的方法是通过DI容器。”
   如果让DI容器(如Autofac)帮你管理DbContext实例及其生命周期,就可以避免以上所有这些麻烦。如果您还使用仓储或类似的抽象,请确保它们的生命周期与DbContext的生命周期一致。ASP.NET Core内置的DI容器和Helper能在Scoped 生命周期类型中为EF Core做出正确的配置。这意味着每个请求将创建一个新的DbContext实例。且这个请求中,任何想使用DbContext实例的操作都共享同一实例。在请求结束时将其清理并释放。如果您使用的是Autofac和EF 6,Scoped就是每个请求只使用一个实例的意思。

using语句和DbContext

   使用using语句可能的问题:

  • 您释放了一个DbContext,使得一个实体无法保存
  • 您异步地把DbContext传递给另一个服务,但是在它被(另一个服务)使用前,就在原始服务中的using块中将其释放
  • 当同时当使用构造函数注入并在ConfigureServices 或者 一个Autofac 模块中添加一行代码这种正确的的行为时(即同时使用using和容器管理),整个应用程序范围内显得代码(不必要的)重复和混乱。

多个DbContext的问题

   与using语句和DbContext密切相关的问题是:如果有多个DbContext(因为该using语句通常会创建一个新实例)。
                “如果您有多个DbContext尝试使用相同的实体实例,那么您将承受巨大的痛苦。”
   考虑这个简单的示例,它包含了一个Controller和一个service,两者同时在使用dbContext。

避免用using包装DbContext【翻译】

   假设在Index方法中,从数据库中读取 starship时,它的name属性值为“ Millenium Falcon”。下次访问Index时,name属性值是什么?

   SaveChanges()被调用时不执行任何操作。db实例在StarshipService中并未跟踪该实体。所以名称将保持不变。
   那么,我们可以这样解决这个问题。让我们附加实体。这是更新后的service:

避免用using包装DbContext【翻译】

   再次运行。现在Name的值是什么?

   SaveChanges()仍然不执行任何操作。实体的name被更新,该实体依然未跟踪。
   让我们再尝试一次:

避免用using包装DbContext【翻译】

   现在,它会起作用吗?你觉得如何?

   是的,现在name的值已更新为“ Millenium Falcon *”,下次是“ Millenium Falcon **”,等等。

   要正确地得到预期的行为,需要进行大量的尝试工作。这段代码是脆弱且重复的,更糟的是,具有隐藏的暂存依赖性。

   那么,MVC5/EF6的旧代码中要怎么使用Autofac呢?

安装Nuget软件包

   安装Autofac.MVC5 nuget软件包。与.NET Framework nuget包不同,它不会添加一堆类,但你仍然需要将它们连接起来。
   进到global.asax文件中更新Application_Start():

避免用using包装DbContext【翻译】

   当你成功运行它,你还可以把它们放置到一个模块中,并把它的helper放到在App_Start目录中。

   这部分代码中所做的事情有: 

  • 配置Autofac的依赖项容器
  • 设置它,以创建controller
  • 设置它,以创建 ApplicationDbContext
  • 设置它,以创建 StarshipService
  • 使用 InstancePerRequest设置上面两个
  • 配置MVC5以使用Autofac来解决其依赖性

   这可能也就需要用5分钟。更新之后还会有混乱的代码吗?好了,服务现在看起来像这样:

避免用using包装DbContext【翻译】

   另外,控制器现在看起来像这样:

避免用using包装DbContext【翻译】

   请注意,这两种类型现在都遵循显式依赖项原则。同时注意到,在解耦之后的代码没完全没有new关键字,这与显式依赖原则有关。

                “方法和类应显式要求(通常通过方法参数或构造函数参数)它们所需要的协作对象才能正常运行。”

   不用对所引用对象的隐式依赖感到惊讶。如果需要引用某个类,应该在构造函数中引入它(注:依赖注入)。如果要将类进行解耦,,则应该声明一个抽象类(或接口),而不是直接使用new创建实例或者调用静态方法。

总结

   EF和EF Core可以为您节省大量时间,并使你更容易地关注领域模型而不是底层的数据库问题。但是如果没有正确使用它们,当你尝试找出它们出现异常的原因时,它们也会让你很头痛。避免直接实例化和避免using块都将使您的代码更容易使用。对于ASP.NET(Core)应用程序,应确保每个请求有且仅具有一个DbContext实例,而实现此目的的最佳方法是使用诸如Autofac之类的DI容器(或ASP. NET Core内置的 ServiceCollection)。

 

本文翻译自 https://ardalis.com/avoid-wrapping-dbcontext-in-using/

 

发表评论

评论已关闭。

相关文章