大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说避免用using包装DbContext【翻译】「建议收藏」,希望您对编程的造诣更进一步.
![避免用using包装DbContext【翻译】[数据库教程]](/www.yht7.com/upload/image/images/imgsql/25.jpg "避免用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/
避免用using包装DbContext【翻译】
原文地址：https://www.cnblogs.com/Euler-Jiaxu/p/14305773.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/6547.html
