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

Question

我想在项目中使用分层体系结构和EF，Repository和UoW模式。

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

DAL or BLL？

Answer 1

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

更多关于此here和here。

Answer 2

DAL是数据访问层的首字母缩略词。 DbContext，存储库和Unit Of Work与处理数据有关，因此您应该将它们放在DAL中。

Answer 3

“应该”在这里可能不是正确的词，因为在这个问题上有很多意见。 如果要实现这些模式出了书，我会从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

但其实我已经开始层这样的：

控制器/逻辑< - 创建和转换业务逻辑和边界对象。

库< - 凡涉及持久性和转化实体和查询逻辑对象

商店< - 当存储机制的实际实现居住。这是从一个接口后面抽象出来的。

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

这是与其他模式的关系，这只是我对此的看法。

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

我喜欢做的是开始一个InMemory存储，我注入到我的控制器。只要该商店开始为多个实体提供服务，并且持久性逻辑越来越复杂 - 我将其重构为顶层存储库。一旦我所有的测试都通过了，并且按照我的要求进行工作，我就开始创建该商店的基于数据库或文件系统的实现。

我的意见再一次在这里，因为这是一个相当普遍的问题，它只有很少的“真实”的答案，只是很多意见。

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

Answer 4

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