我正在进行项目，我需要设计 DAL。我将在大部分项目中使用Entity Framework，在一些性能敏感领域使用Dapper。
我正在考虑使用存储库模式，但后来 EF 在某种意义上已经实现了这种模式。但 Dapper 的情况并非如此。然后我想知道在我的 DAL 中混合存储库和服务模式是否有效？还是会跨入业务逻辑层？
我正在考虑构建的示例结构：
MyProjectName.Main
Views/
Controllers/
Infrastructure/
...
MyProjectName.DAL
DataService.EF/
fileName.cs
...
DataService.Dapper/
fileName.cs
...
【问题讨论】：
标签： asp.net-mvc entity-framework design-patterns dapper
查看Bradley Braithwaite 创建的EF + Dapper Hybrid Implementation。
GitHub 仓库：https://github.com/bbraithwaite/HybridOrm
随附的博文：ORM：Don't Reinvent the Wheel
在构建项目层以避免“流血”方面，他是这样做的。
【讨论】：
EF 或任何其他 ORM 不实现存储库。存储库旨在将域与持久性分离。 Domain 与域对象一起使用，EF/Nhibernate/Dapper 等与代表关系数据库的OOP 视图的持久性实体一起使用。
看到区别了吗？一个需要业务对象，另一个处理数据结构。它们相似但不一样。领域模型概念、行为和用例，持久性关心存储数据以便快速检索。不同的职责。存储库充当它们之间的中介，“转换”持久性结构中的域对象，反之亦然。
始终，ORM 是存储库的实现细节。对于 CRUD 应用程序，您实际上并没有域，而是直接与数据库打交道，即（微）ORM。在这种情况下，Repo 仅作为一种外观才有意义，以赋予数据访问一些业务意义（GetOrders 更容易理解，整个 Linq 或 5 行 SQL 连接 3 个表）。
Repository 接口是在需要的地方定义的，但它是在 Persistence (DAL) 中实现的。与服务相同，它们可以在域中定义（作为接口），而它们的实现可以在 DAL 中。虽然存储库实现几乎总是 DAL 的一部分，但只有一些服务驻留在 DAL 中，原因很简单，它们更容易以这种方式完成工作。其他服务可以直接使用存储库（通常通过构造函数注入）并且不接触 DAL。
无论你使用什么模式，试着了解它们的实际目的，并始终考虑解耦。
【讨论】：
我可以说您的问题很常见，并且有一个通用的解决方案 - CQRS (Command Query Responsibility Segregation)。当人们在他们的项目中练习 DDD (Domain Driven Design) 并遇到 some performance-sensitive areas 的困难时，这种模式被广泛使用。
您将使用什么 ORM 没有区别。可以有不同的组件来检索数据。
您可以使用 Repositories 或/和 Entity Framework 并使用 most of the project 的所有功能来执行 C-reate R-ead U-pdate D-elete 操作。
但对于 some performance-sensitive areas，您可以使用 查询。他们将返回由 Dapper 填充的 DTO（R-ead 操作）。
【讨论】：
我推荐你看这个教程：Entity Framework in the Enterprise 在这里，作者很好地解释了Entity Framework和Repository Pattern，最后，她实现了2个Repositories：一个用于常规App，另一个用于断开连接的App。她提出的一个很好的观点是，没有一件事适合所有人。基本上，您可以根据您的特定需求调整您的存储库。
对于您的情况，我将实现 2 个存储库：一个位于 EF 之上，另一个用于 Dapper。
【讨论】：