最近我发现以下方法对我从事的许多项目都非常有效。 然而，问题是，我读到ef核心DbContext本身就是一个UoW，我不应该创建自己的UoW和存储库。但在这种情况下，我无法从应用程序逻辑层中抽象出我的持久性层。
TL;DR问题是：是否有可能没有自己的存储库，也没有自己的UoW，并且仍然遵循提到的架构，将DbContext作为UoW？
我的架构如下：
第 1层(最内层(： 聚合、实体、POCO 域类、值对象
第 2 层：域服务
第 3 层：应用程序服务(CQRS 命令、查询、处理程序(和存储库接口
第 4A 层：(持久性层( 存储库实现(此处注入 DbContext( EF 核心映射(ORM 映射(
Layer 4B：ASP MVC API(DI在此注册(
API 的控制器只是发出命令和查询(通过 MediatR(。
上述方法的优点是应用核心(第 1、2 和 3 层(完全从持久性中抽象出来。 缺点是你真的必须编写自己的存储库。
这是正确的方法吗？还是我错过了什么？
为什么 DbContext 是一个工作单元？
DbContext 通过一次提交 (SaveChanges( 捕获您在单个事务中所做的所有更改。
为什么你不应该创建自己的？
理想情况下，您应该只通过一个事务提交到一个数据存储。如果要在多个事务中保存到多个数据存储，或者在多个事务中保存到同一数据存储，则可能会面临数据损坏的可能性。如果您跨多个数据存储使用分布式事务，那么上帝会帮助您。
因此，保存更改应该就足够了，那么为什么要创建自己的更改呢？
但是抽象呢？
如果 SaveChanges 就足够了，那么我们如何抽象出对 EF 的依赖？您可以使用单个方法Commit引入IUnitOfWork接口，您可以通过调用 DbContext.SaveChanges 来实现。
还有存储库？
我不确定我是否理解不创建存储库是一项硬性规则。作为抽象出持久性层的一部分，使用诸如 IRepository 之类的层来提供这种分离会很有帮助。也就是说，您不应该为每个表创建存储库。每个聚合的存储库更合适。每个存储库将加载整个聚合，以确保聚合边界内的一致性。
。
总的来说，如果你不理解该建议背后的原因，我会警告不要遵循绝对的建议。您应该能够为自己提供相同的起始信息，得出相同的结论。否则，您只是将死记硬背应用于并不总是从该方法中受益的模式。