具有实体框架和存储库模式的域驱动设计答案

【问题标题】：Domain-Driven Design with Entity Framework & Repository Pattern [closed]具有实体框架和存储库模式的域驱动设计
【发布时间】：2018-12-27 22:21:21
【问题描述】：

我曾经处理具有 Service Layer 包含所有业务逻辑的简单应用程序。在领域驱动设计中，将业务逻辑保持在丰富的模型中是很常见的。

观看了 Pluralsight 的教程，其中提到了存储库，并注意到存储库通常包含基本的 CRUD 操作（创建、更新、获取和删除实体）。关于实体框架，没有做太多解释。

Entity Framework 6 和 Entity Framework Core 已经提供了开箱即用的 Repository/UoW。 我想知道在这种情况下我们是否可以省略创建存储库层？

那么，我如何想象没有单独的 Repository 层的应用程序......

我的理解是：

例如，我们将Customer 模型作为聚合根（富域模型）。该模型具有一对多关系ICollection<Payment> Payments。另外，根据 DDD - 我们将逻辑保留在模型中 - 所以我们有 MakePayment 方法。

代码如下：

public class Customer
{
    public virtual ICollection<Payment> Payments { get; set; }

    // ... other properties/collections

    public void MakePayment(decimal amount)
    {
        this.Payments.Add(new Payment() { Amount = amount });
    }
}

使用Entity Framework，我们可以快速加载整个树，结果Customer 已经映射了所有Payments。

（比如说，我们处理一个 ASP.NET WebAPI 应用程序）

所以，我想，为了付款，我们执行以下操作：

在我们的控制器/服务中，我们获取客户（例如通过id）
然后跟着代码customer.MakePayment(10);
之后我们调用dbContext.SaveChanges()方法
DbContext 跟踪更改并存储付款 - Bingo！

我的理解正确吗？

关于服务层：

这样的 Web 应用中是否可以使用带 DDD 的服务层？

我仍然认为将代码保存在控制器中不一定是正确的做法（即使使用 DDD）只要例如WPF 应用程序可能需要部分功能 - 因此我们可以使用服务层。

似乎是最理想的方法，不是吗？

【问题讨论】：

这个问题太宽泛/基于观点，但我认为你走在正确的轨道上。附加 repo，否，服务层是，带有 EF 类对象的 DDD：也许。
感谢您的快速回复@GertArnold。但我不认为它太宽泛......实体框架和其他框架不断发展，恕我直言，对于使用稍微过时的教程开始学习 DDD 的开发人员来说，越来越困惑。再次感谢！
一些教程甚至不便宜，考虑到现代软件堆栈，它们仍然没有涵盖重要方面:)
直到像 Ayende Rahien 这样有影响力的人开始criticize the pattern openly 之前，开发人员社区才慢慢开始接受我们可能不需要的想法。而且，正如你所说，对于像 EF 这样的 ORM，它是一个附加 repo 层，这使得它更加成问题。

标签： c# entity-framework domain-driven-design repository-pattern

【解决方案1】：

我想知道在这种情况下我们是否可以省略创建存储库层？

在我看来，您不能省略存储库层。通常，Repository 负责Save and Rebuild Aggregate Root，而您的域实体不是您的数据库实体。 EF 实体不是您的域实体。

在这样的网络应用中使用 DDD 服务层可以吗？

当然你可以保留你的服务层，实际上，你可以在 DDD 中称它为应用层，但是你需要注意这个层应该包含什么。

【讨论】：

【解决方案2】：

我想知道在这种情况下我们是否可以省略创建存储库层？

如第一段 here 中所述，请考虑直接使用通用存储库 (DbSet)。避免创建额外的 Repository 层。

我的理解正确吗？

IMO，如果您正确实施了工作单元（您在问题中解释的每个请求的会话）模式，您的理解是正确的。它应该是这样工作的。

在这样的网络应用中使用 DDD 服务层可以吗？

使用 DDD，您的域模型包含相关逻辑。但是，总有一种逻辑不属于任何领域模型。该逻辑通常在服务中使用。所以是的，您可能仍然需要使用 DDD 的服务。只是，它不会包含您的所有逻辑，因为大部分逻辑都包含在模型中。

对于 DDD，请考虑使用 CQRS。使用 CQRS，您可以分离对数据存储的读取和写入。在这种情况下，存储库是可选的。如上所述，您可以使用 ORM 公开的 Generic Repository。

【讨论】：