避免用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。

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

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

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

   SaveChanges（）仍然不执行任何操作。实体的name被更新，该实体依然未跟踪。
   让我们再尝试一次：

   现在，它会起作用吗？你觉得如何？

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

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

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

安装Nuget软件包

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

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

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

• 配置Autofac的依赖项容器

• 设置它，以创建controller

• 设置它，以创建 ApplicationDbContext

• 设置它，以创建 StarshipService

• 使用 InstancePerRequest设置上面两个

• 配置MVC5以使用Autofac来解决其依赖性

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

   另外，控制器现在看起来像这样：

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

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

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

总结

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

 

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