我想在项目中使用分层架构和EF，Repository和UoW Pattern。
DBContext，Repository和UnitOfWork应该在哪个层？
DAL还是BLL？
答案 0 :(得分：0)
DAL是数据访问层的首字母缩写。 DbContext，存储库和工作单元与处理数据有关，所以你一定要将它们放在DAL中。
答案 1 :(得分：0)
我会将您的DbContext实现放在DAL（数据访问层）中。您可能会对此有不同的看法，但我不会实现存储库或工作模式单元。从技术上讲，DBContext是工作单元，IDbSet是一个存储库。通过实现自己的实现，您可以在抽象之上添加抽象。
答案 2 :(得分：0)
＆＃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;答案，只是很多意见。
大多数意见都是有效的，它们只是有不同的优点和缺点，重要的是要弄清楚你需要哪些优势，以及如何处理弱点。
答案 3 :(得分：0)
您的存储库应该引用DbSet<T>个对象，一旦您从一个或多个存储库添加，更新或删除，您应该从SaveChanges调用UnitOfWork。因此，您应该将DbContext放入工作单元实施中。