DDD 聚合和 entity framework。哪种方式更可取？

Question

我对这个问题有点困惑。我有一个在数据库中表示的实体 Product。看起来像POCO。这是示例（为了简单起见，我使用属性而不是流利的 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.

~~的包装器~~

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

我明白我真正的问题听起来是这样的："Should I separate Data model and domain model? Can I change EF entities from Anemic to Rich?"

Answer 1

为了确保您的实体的持久性无知，我发现 EF Fluent Mapping to be better than Data Annotations. The mappings are declared in an external file, thus normally your entity doesn't have to change if something in the persistence layer changes. However, there are still some things you can't map 和 EF。

您链接到的

Vaughn 的 "backing state object" 解决方案很好，但它是一个额外的间接层，给您的应用程序增加了相当多的复杂性。这是个人品味的问题，但我只会在您的实体中绝对需要由于 EF 缺点而无法直接映射的内容时使用它。它也适用于事件溯源方法。

Answer 2

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

举个例子，对于Student和Course的范式——一个学生可以上很多门课程，一个课程可以有很多学生，因此在你的数据库设计中是多对多的关系。这将由三个 table 组成：Student、Course、StudentToCourse。

EF 将允许您使用 Fluent API 映射在关系的任一侧创建许多集合，而无需在模型中定义中间 table (StudentToCourse)（StudentToCourse 没有存在于域模型中），您的域中只需要两个类，学生和课程。而在 LinqToSQL 中，您必须将模型中的所有三个定义为数据实体，然后在数据实体和域模型之间创建映射，从而导致大量管道工作容易出现错误。

贫领域模型与富领域模型的争论应该对模型和数据库之间的映射影响不大table，但重点在于放置行为的位置 - 在领域模型或服务中层.

DDD 聚合和 entity framework。哪种方式更可取？

DDD aggregate and entity framework. Which way is preferable?

c#

orm

domain-driven-design

entity-framework