asp.net-mvc – 存储库与DAL中的服务模式：EF和Dapper

发布时间：2020-12-15 20:10:10 所属栏目：asp.Net 来源：网络整理

导读：我正在开展项目,我需要设计DAL.我将使用大多数项目的实体框架和Dapper对某些性能敏感的领域. 我正在考虑使用Repository模式,但是EF已经在某种意义上实现了这种模式.但是,Dapper并不是这样.那么我想知道在我的DAL中混合Repository和Service模式是否有效？或者

我正在开展项目,我需要设计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.

无论你使用什么样的模式,试图理解他们的实际目的,并总是考虑去耦.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!