DAL中的仓储模式与服务模式：EF和Dapper

Question

我正在设计一个项目，需要设计数据访问层（DAL）。 大部分项目将使用Entity Framework，而在一些性能敏感的领域中将使用Dapper。

我曾考虑使用仓储库模式，但是EF已经在某种意义上实现了这种模式。但这并不适用于Dapper。所以我想知道，在我的DAL中混合使用仓储库模式和服务模式是否有效？或者这会涉及到业务逻辑层？

我考虑构建以下样例结构：

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

- sakura-bloom

Answer 1

请查看Bradley Braithwaite创建的EF + Dapper混合实现。

GitHub代码库：https://github.com/bbraithwaite/HybridOrm

附带博客文章：ORM：不要重复造轮子

为了避免“耦合”，他是这样构建项目层次结构的。

从博客文章：使用Dapper创建数据仓库

- Shiva

Answer 2

我可以说，您的问题很常见，也有一个常见的解决方案—— CQRS (命令查询职责分离)。当人们在他们的项目中实践DDD (领域驱动设计)时，遇到了一些性能敏感的区域，这种模式被广泛使用。

无论你使用什么ORM，都没有区别。拥有不同的组件来检索数据是可以接受的。

你可以使用存储库或/和Entity Framework并使用它的所有功能进行大部分项目来执行C-reate R-ead U-pdate D-elete操作。

但对于一些性能敏感的区域，你可以使用查询。他们将返回由Dapper（R-ead操作）填充的DTOs。

- Ilya Palkin

Answer 3

EF或其他ORM并没有实现仓储模式。仓储模式旨在将领域与持久化分离。领域使用领域对象，EF / Nhibernate / Dapper等使用代表关系数据库的持久化实体。

看到区别了吗？一个需要业务对象，另一个则处理数据结构。它们相似但不相同。领域模型概念、行为和用例，持久化关心存储数据以便快速检索。不同的职责。仓储作为它们之间的中介，将领域对象“转换”为持久化结构反之亦然。

始终如此，ORM是仓储实现的细节。对于CRUD应用程序，您实际上没有领域，直接处理数据库即(micro)ORM。这种情况下，Repo只有作为外观才有意义，以给数据访问提供业务含义（GetOrders比整个Linq或5行SQL连接3个表更容易理解）。

仓储接口在需要的地方定义，但在持久化层(DAL)中实现。服务也是一样，可以在领域中定义（作为接口），而它们的实现可以在DAL中。虽然仓储实现几乎总是DAL的一部分，但某些服务仅驻留在DAL中，原因很简单，它们这样做更容易完成工作。其他服务可以直接使用仓储（通常通过构造函数注入），而不涉及DAL。

无论使用哪种模式，都要了解其实际目的，并始终考虑解耦。

- MikeSW

---

谢谢您详细的解释。 - sakura-bloom

Answer 4

我建议你观看这个教程：企业级实体框架 在这里，作者很好地解释了实体框架和仓储模式，并最终实现了两个仓库：一个用于传统应用程序，另一个用于断开连接的应用程序。她提出的一个好点是没有一种东西适合所有情况。基本上，你可以根据自己的需要来调整你的仓库。

对于你的情况，我将实现两个仓库：一个在EF之上，另一个使用Dapper。

- Jaider