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

Question

最近我发现以下方法对我参与的许多项目都很有效。然而，问题是，我读到 ef core DbContext 本身就是一个 UoW，我不应该创建自己的 UoW 和存储库。但在这种情况下，我无法从应用程序逻辑层中抽象出持久层。

TL;DR 问题是： 是否有可能既不拥有自己的存储库也不拥有 UoW，并且仍然遵循上述架构，并将 DbContext 作为 UoW？

我的架构如下：

第 1 层（最内部）：聚合、实体、POCO 域类、值对象

第 2 层： 域服务

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

第 4A 层：（持久层）存储库实现（此处注入 DbContext）EF Core 映射（ORM 映射）

第 4B 层： Asp MVC API（此处注册 DI）

API 的控制器只是发出命令和查询（通过 MediatR）。

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

这是正确的方法吗？或者我错过了什么？

Answer 1

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

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

为什么不应该创建自己的？

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

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

但是抽象呢？

如果 SaveChanges 就足够了，那么我们如何抽象出我们对 EF 的依赖？您可以使用单个方法Commit引入IUnitOfWork接口，您可以通过调用 DbContext.SaveChanges 来实现该方法。

和存储库？

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

...

一般来说，如果您不理解该建议背后的推理，我会警告不要遵循绝对化的建议。给定相同的起始信息，您应该能够得出相同的结论。否则，您只是将死记硬背应用于并不总是从该方法中受益的模式。