DBContext，Repository和UnitOfWork应该在哪一层？

Question

我想在项目中使用分层架构和EF，Repository和UoW Pattern。

DBContext，Repository和UnitOfWork应该在哪个层？

DAL还是BLL？

Answer 1

DAL是数据访问层的首字母缩写。 DbContext，存储库和工作单元与处理数据有关，所以你一定要将它们放在DAL中。

Answer 2

我会将您的DbContext实现放在DAL（数据访问层）中。您可能会对此有不同的看法，但我不会实现存储库或工作模式单元。从技术上讲，DBContext是工作单元，IDbSet是一个存储库。通过实现自己的实现，您可以在抽象之上添加抽象。

有关此here和here的更多信息。

Answer 3

＆＃34;宜＆＃34;这里可能不是正确的词，因为关于这个主题有很多观点。 如果你想从书中实现这些模式，我会从ASP.NET人员那里看看这个链接： https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

但实际上我已经开始像这样分层了：

Controller / Logic＆lt; - 创建和转换业务逻辑和边界对象。

Repository＆lt; - 与持久性和转换实体和查询对象相关的逻辑

Store＆lt; - 存储机制的实际实现所在的位置。这是在界面后面抽象出来的。

这种方式利用了这样一个事实，即业务逻辑和存储库逻辑都是可测试的，解耦的并且可以自由地使用任何持久性机制 - 或者缺乏持久性机制。没有其他应用程序知道它的任何信息。

这也适用于其他模式，这只是我对此的看法。

DbContext永远不应超越DAL的边界，如果你想把你的存储库或工作单元放在那里，你可以自由地，只是不要让它们向上泄漏他们的细节或依赖。在我看来，DbContext应该尽可能缩小范围，尽可能保持干净 - 你永远不知道上下文的位置......请保护！但是开玩笑说，如果你有一个异步，多线程，多节点，大应用程序，使用这些DbContexts到处传递它们，你将会遇到一般的并发和数据争用问题。

我喜欢做的是从InMemory商店开始，我注入我的控制器。一旦该商店开始为多个实体提供服务，并且持久性逻辑变得越来越复杂 - 我将它重构到一个存储库顶部的商店中。一旦我的所有测试通过并且我按照自己的意愿工作，我就会开始创建该商店的数据库或基于文件系统的实现。

我的意见再次在这里，因为这是一个相当普遍的问题，很少有＆＃34;真正的＆＃34;答案，只是很多意见。

大多数意见都是有效的，它们只是有不同的优点和缺点，重要的是要弄清楚你需要哪些优势，以及如何处理弱点。

Answer 4

您的存储库应该引用DbSet<T>个对象，一旦您从一个或多个存储库添加，更新或删除，您应该从SaveChanges调用UnitOfWork。因此，您应该将DbContext放入工作单元实施中。