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 + Dapper Hybrid Implementation创建的Bradley Braithwaite。

GitHub回购：https://github.com/bbraithwaite/HybridOrm

随附博客文章：ORM：Don't Reinvent the Wheel

在构建项目图层以避免“流血”方面，这是他如何做到的。

来自博客文章：Creating Data Repository Using Dapper

Answer 2

我可以说你的问题很常见，并且有一个共同的解决方案 - CQRS (Command Query Responsibility Segregation)。当人们在他们的项目中练习DDD (Domain Driven Design)并且遇到 some performance-sensitive areas 的困难时，这种模式被广泛使用。

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

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

但是对于 some performance-sensitive areas ，您可以使用查询。他们将返回由Dapper填充的DTO（ R -ead操作）。

Answer 3

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

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

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

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

无论您使用何种模式，都要尝试了解它们的实际目的，并始终考虑脱钩。

Answer 4

我建议您观看本教程：Entity Framework in the Enterprise 在这里，作者非常好地解释了实体框架和存储库模式，最后，她实现了2个存储库：一个用于传统应用程序，另一个用于断开连接的应用程序。她提出的一个好处是，没有一件事适合所有人。基本上，您可以根据您的特定需求调整您的存储库。

对于您的情况，我将实现2个存储库：一个在EF顶部，另一个在Dapper。