DAL中的存储库与服务模式: EF和Dapper
我在做项目，我需要设计DAL。我将在大多数项目中使用Entity Framework，在一些性能敏感的领域使用Dapper。
我正在考虑使用Repository模式，但是EF已经在某种意义上实现了这个模式。但Dapper的情况并非如此。那么，我想知道在我的DAL中混合存储和服务模式是否有效？或者这是否会跨入业务逻辑层？
我想要建立的一个样本结构：
MyProjectName.Main
Views/
Controllers/
Infrastructure/
...
MyProjectName.DAL
DataService.EF/
fileName.cs
...
DataService.Dapper/
fileName.cs
...回答 4
Stack Overflow用户
发布于 2013-11-05 19:50:08
EF或任何其他ORM都不实现存储库。Repository旨在将域与持久性分离开来。域与域对象一起工作，EF/Nhibernate/Dapper等处理持久化实体，后者表示关系数据库的OOP视图。
看到区别了吗？一个需要业务对象，另一个需要处理数据结构。它们是相似的，但它们并不相同。领域模型的概念，行为和用例，持久化关心存储数据，以便快速检索。不同的责任。存储库充当它们之间的中介，在持久化结构和逆序中“转换”域对象。
ORM总是存储库的实现细节。对于CRUD应用程序，您没有真正的域，您直接处理的db，即(微)ORM。在这种情况下，Repo只有作为一个外观才有意义，以使数据访问具有一定的业务意义( GetOrders更容易理解整个Linq或5行SQL连接了3个表)。
Repository接口是在需要的地方定义的，但它是在持久性(DAL)中实现的。与服务一样，可以在域中定义它们(作为接口)，而它们的实现可以在DAL中实现。虽然Repository实现几乎总是DAL的一部分，但是只有一些服务驻留在DAL中，原因很简单，因为这样做对他们来说更容易。其他服务可以直接使用存储库(通常通过构造函数注入)，并且不接触DAL。
无论你使用什么模式，都要试着理解它们的实际目的，并且总是考虑解耦。
Stack Overflow用户
发布于 2013-11-05 19:08:58
查看一个由EF + Dapper混合实现创建的布拉德利·布莱斯韦。
GitHub回购：https://github.com/bbraithwaite/HybridOrm
随附博客: ORMs：不要重新发明车轮
在构建项目层以避免“出血”方面，他是这样做的。
来自博文：使用Dapper创建数据仓库
Stack Overflow用户
发布于 2013-11-05 19:16:06
我可以说，您的问题很常见，而且有一个共同的解决方案-- CQRS (命令查询责任分离)。当人们在他们的项目中实践some performance-sensitive areas.并面临领域驱动设计困难时，这种模式被广泛使用。
您将使用什么ORM并没有什么不同。可以有不同的组件来检索数据。
您可以使用most of the project的存储库或/和实体框架，并使用其所有特性来执行C-reate R-ead U-pdate DE 217-elete操作。
但是对于some performance-sensitive areas，您可以使用查询。它们将返回由Dapper填充的DTO (R-ead操作)。
https://stackoverflow.com/questions/19796223
复制相似问题
腾讯云开发者
