12

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

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

我正在考虑构建的示例结构：

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

4 回答 4

10

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

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

随附的博客文章：ORM：不要重新发明轮子

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

项目布局

来自博客文章：使用 Dapper 创建数据存储库

于 2013-11-05T19:08:58.090 回答
8

我可以说您的问题很常见，并且有一个通用的解决方案 - 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你可以使用Queries。他们将返回由 Dapper 填充的 DTO（R -ead 操作）。

于 2013-11-05T19:16:06.520 回答
8

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

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

始终，ORM 是存储库的实现细节。对于 CRUD 应用程序，您实际上并没有域，而是直接与数据库打交道，即（微）ORM。在这种情况下，Repo 仅作为一种外观才有意义，以赋予数据访问一些业务意义（GetOrders更容易理解整个 Linq 或 5 行 SQL 连接 3 个表）。

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

无论你使用什么模式，试着理解它们的实际目的并始终考虑解耦。

于 2013-11-05T19:50:08.480 回答
0

推荐你看这个教程：企业中的实体框架 在 这里，作者很好地解释了实体框架和存储库模式，最后，她实现了2个存储库：一个用于常规应用程序，另一个用于断开连接的应用程序。她提出的一个很好的观点是，没有一件事适合所有人。基本上，您可以根据您的特定需求调整您的存储库。

对于您的情况，我将实现 2 个存储库：一个位于 EF 之上，另一个用于 Dapper。

于 2016-02-20T16:58:12.277 回答