DAL中的存储库与服务模式:EF和Dapper

Question

我正在研究项目,我需要设计DAL.我将Entity Framework用于大部分项目和Dapper一些对性能敏感的领域.

我正在考虑使用Repository模式,但是EF在某种意义上已经实现了这种模式.但是Dapper的情况并非如此.然后我想知道在我的DAL中混合存储库和服务模式是否有效？或者这会进入业务逻辑层？

我想要建立一个样本结构:

MyProjectName.Main
    Views/
    Controllers/
    Infrastructure/
    ...
MyProjectName.DAL
    DataService.EF/
        fileName.cs
        ...
    DataService.Dapper/
        fileName.cs
        ...

Answer 1

检查出的EF +小巧精致的混合实现的是布拉德利·布雷斯韦特创造.

GitHub Repo:https://github.com/bbraithwaite/HybridOrm

伴随博客文章:ORM:不要重新发明轮子

在构建项目层以避免"流血"方面,这是他如何做到的.

来自Blog Post:使用Dapper创建数据存储库

Answer 2

我可以说你的问题很常见,而且它有一个共同的解决方案 - CQRS(Command Query Responsibility Segregation).当人们在他们的项目中练习DDD(领域驱动设计)并面临困难时,这种模式被广泛使用some performance-sensitive areas.

您将使用的ORM没有区别.拥有检索数据的不同组件是可以的.

您可以使用存储库或/和实体框架并使用其所有功能most of the project来执行C -reate R -ead U -pdate D -elete操作.

但是some performance-sensitive areas你可以使用查询.他们将返回由Dapper填充的DTO(R -ead操作).

Answer 3

EF或任何其他ORM不实现存储库.存储库旨在将域与持久性分离.Domain使用域对象,EF/Nhibernate/Dapper等使用持久性实体,它代表关系数据库的OOP视图.

看到不同？一个需要业务对象,另一个需要处理数据结构.它们很相似,但它们不一样.域模型概念,行为和用例,持久性关心存储数据以便快速检索.责任不同.Repository充当它们之间的中介,"转换"持久性结构中的Domain对象,反之亦然.

始终,ORM是存储库的实现细节.对于CRUD应用程序,您实际上没有域名,您直接处理数据库即(微)ORM.在这种情况下,Repo仅作为一个外观才有意义,为数据访问提供一些商业意义(GetOrders更容易理解整个Linq或5行SQL加入3个表).

Repository接口是在需要的地方定义的,但它是在Persistence(DAL)中实现的.与服务相同,它们可以在域中定义(作为接口),而它们的实现可以在DAL中.虽然Repository实现几乎总是DAL的一部分,但只有一些服务驻留在DAL中,原因很简单,因为它们更容易以这种方式完成工作.其他服务可以直接使用存储库(通常通过构造函数注入),不要触及DAL.

无论您使用何种模式,都要尝试了解它们的实际目的,并始终考虑去耦.