DDD 聚合和实体框架。哪种方式更可取？答案

【问题标题】：DDD aggregate and entity framework. Which way is preferable?DDD 聚合和实体框架。哪种方式更可取？
【发布时间】：2016-05-17 07:51:57
【问题描述】：

我对这个问题有点困惑。我有一个在数据库中表示的实体Product。它看起来像 POCO。这是示例（为简单起见，我使用属性而不是 fluent api）。

public class Product
{
    [Key]
    public int Id { get; set; }   
    //other properties that have mapping to db
}

但现在我想避免AnemicDomainModel anti-pattern

所以我要用没有映射到数据库的方法和属性来填充Product 模型，所以我应该使用[Ignore]。

public class Product
{
    [Key]
    public int Id { get; set; }   
    [Ignore]
    public object FooProperty { get; set; } 
    //other properties that have mapping to db
    //other properties and methods that do not have mapping to db
}

我认为这种方式会破坏我的模型。在this article 我找到了可接受的解决方法。它的想法是将Product（域模型）和ProductState（存储在数据库中的产品状态）分开。所以Product 是ProductState 的包装器。

我真的很想知道其他开发者的看法。非常感谢您的回答。

我知道我真正的问题听起来是这样的：“我应该将数据模型和域模型分开吗？我可以将 EF 实体从 Anemic 更改为 Rich 吗？”

【问题讨论】：

Aggregate root with Entity Framework using Domain Driven Design的可能重复

标签： c# entity-framework orm domain-driven-design

【解决方案1】：

为了确保对实体的持久性无知，我发现 EF Fluent Mapping 比数据注释更好。映射在外部文件中声明，因此如果持久层中的某些内容发生更改，通常您的实体不必更改。不过EF还是有some things you can't map。

您链接到的 Vaughn 的“支持状态对象”解决方案很好，但它是一个额外的间接层，给您的应用程序增加了相当多的复杂性。这是个人喜好的问题，但我只会在您绝对需要实体中由于 EF 缺点而无法直接映射的东西的情况下使用它。它还与事件溯源方法配合得很好。

【讨论】：

虽然已经被其他人使用过，但“数据模型”的概念对我来说听起来有点用词不当，因为数据模型已经反映在数据库中。我更喜欢“支持状态”。正如我所说，根据我的经验，引入额外的支持状态层在大多数情况下都是矫枉过正的，但这只是我的意见。关于 POCO 到 POJO，你是什么意思？ POJO 与普通旧 Java 对象一样？
我该去睡觉了。我删除了我的评论，并再次编辑了问题，但您的回答对我绝对有帮助。谢谢。

【解决方案2】：

实体框架的美妙之处在于它允许您使用可以使用 Fluent API 定义的映射将您的数据库表映射到您的域模型，因此不需要单独的数据实体。这与其前身 Linq To SQL 相比，您将每个表映射到一个单独的数据实体。

以以下示例为例，学生和课程的范式 - 一个学生可以学习很多课程，而一个课程可以有很多学生，因此在您的数据库设计中是多对多的关系。这将包含三个表：Student、Course、StudentToCourse。

EF 将允许您使用 Fluent API 映射在关系的任一侧创建许多集合，而无需在模型中定义中间表 (StudentToCourse)（StudentToCourse 在域模型中不存在），您只需在您的域中需要两个课程，学生和课程。而在 LinqToSQL 中，您必须在模型中将这三个都定义为数据实体，然后在数据实体和域模型之间创建映射，这会导致大量管道工作存在漏洞。

贫乏领域模型与丰富领域模型的争论对模型和数据库表之间的映射影响不大，但重点在于您将行为置于何处——在领域模型或服务层中。

【讨论】：