题
我正在研究项目，我需要设计DAL。我将在大多数项目中使用Entity Framework ，在一些性能敏感区域使用Dapper 。
我在考虑使用Repository模式但是EF在某种意义上已经实现了这种模式。但是Dapper的情况并非如此。然后我想知道在我的DAL中混合存储库和服务模式是否有效？或者这会进入业务逻辑层？
我想要建立一个样本结构：
MyProjectName.Main
Views/
Controllers/
Infrastructure/
...
MyProjectName.DAL
DataService.EF/
fileName.cs
...
DataService.Dapper/
fileName.cs
...
一般承认的答案
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。
无论你使用什么模式，试着了解它们的实际目的，并始终考虑去耦。
热门答案
查看Bradley Braithwaite创建的EF + Dapper Hybrid实施 。
GitHub Repo： https ： //github.com/bbraithwaite/HybridOrm
伴随博客文章：ORM： 不要重新发明轮子
在构建项目层以避免“流血”方面，这是他如何做到的。
来自Blog Post： 使用Dapper创建数据存储库
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow