我正在开展项目,我需要设计DAL.我将使用大多数项目的实体框架和Dapper对某些性能敏感的领域.
我正在考虑使用Repository模式,但是EF已经在某种意义上实现了这种模式.但是,Dapper并不是这样.那么我想知道在我的DAL中混合Repository和Service模式是否有效？或者是否会进入业务逻辑层？
我正在考虑的一个示例结构：
MyProjectName.Main
Views/
Controllers/
Infrastructure/
...
MyProjectName.DAL
DataService.EF/
fileName.cs
...
DataService.Dapper/
fileName.cs
...
解决方法
EF或任何其他ORM不实现存储库.存储库旨在将域与持久性分离.域使用域对象,EF / Nhibernate / Dapper等与持久性实体一起工作,表示关系数据库的OOP视图.
看到不同？一个需要业务对象,另一个处理数据结构.他们是相似的,但它们是不一样的.域模型概念,行为和用例,持久性关心存储数据,以便快速检索.不同的责任存储库作为它们之间的调解器,“转换”持久化结构中的域对象和对象.
始终,ORM是存储库的实现细节.对于CRUD应用程序,您没有真正拥有一个域,您直接处理数据库即(微)ORM.在这种情况下,Repo只有作为一个立面才有意义,为数据访问提供一些商业意义(Getorders更容易理解整个Linq或5行sql连接3个表).
Repository接口被定义在需要的位置,但它在Persistence(DAL)中实现.与服务相同,它们可以在域中定义(作为接口),而其实现可以在DAL中.虽然存储库实现几乎总是DAL的一部分,但只有一些服务驻留在DAL中,原因很简单,因为他们以更简单的方式来完成他们的工作.其他服务可以直接使用存储库(通常通过构造函数注入),并且不要触摸DAL.
无论你使用什么样的模式,试图理解他们的实际目的,并总是考虑去耦.
