DDD，CQRS，洋葱架构，企业级应用的ef核心

Question

最近，我发现下面的方法对我所做过的许多项目都很有效。但问题是，我读到ef核心DbContext本身就是一个UoW，我不应该创建自己的UoW和存储库。但在这种情况下，我无法将我的持久层从我的应用逻辑层中抽象出来。

TL;DR的问题是：是否有可能没有自己的存储库或UoW，并且仍然遵循所提到的以DbContext作为UoW的体系结构？

我的架构如下：

Layer 1 (最内部)：聚合、实体、POCO域类、值对象

第2层：域服务

第3层：应用程序服务(CQRS命令、查询、处理程序)和存储库接口

层4A:存储库实现(DbContext注入这里) EF核心映射(ORM映射)

层4B: API (DI在这里注册)

API的控制器只发出命令和查询(通过MediatR)。

上述方法的优点是，app核心(第1、2和3层)完全从持久性中抽象出来。缺点是，您确实必须编写自己的存储库。

这样做正确吗？还是我漏掉了什么？

Answer 1

为什么DbContext是一个工作单位？

通过一个提交(SaveChanges).，DbContext捕获您在一个事务中所做的所有更改。

，你为什么不创建你自己的？

理想情况下，您应该只通过一个事务提交一个数据存储。如果要在多个事务中保存到多个数据存储区，或者在多个事务中保存到相同的数据存储区，则可能会遇到数据损坏的可能性。如果您使用的是跨多个数据存储的分布式事务，那么上帝会帮助您。

因此，SaveChanges应该是足够的，那么为什么要创建自己的呢？

，但是抽象呢？

如果SaveChanges是足够的，那么我们如何抽象我们对EF的依赖？您可以使用一个方法IUnitOfWork接口提交，您可以通过调用DbContext.SaveChanges来实现这个接口。

和存储库？

我不确定我是否理解不将创建存储库作为一条艰难的规则。作为将持久性层抽象出来的一部分，有一个诸如IRepository这样的层来提供这种分离是很有帮助的。也就是说，不应该为每个表创建一个存储库。每个聚合存储库更合适。每个存储库将加载整个聚合，以确保聚合边界内的一致性。

…

一般来说，如果你不理解建议背后的理由，我会提醒你不要遵循绝对的建议。如果给自己提供相同的开始信息，你应该能够得出同样的结论。否则，你只是将死记硬背应用于一种并不总是受益于这种方法的模式。