了解 DTO 和贫血域模型答案

【问题标题】：Understanding DTO and Anemic Domain Model了解 DTO 和贫血域模型
【发布时间】：2011-09-19 16:29:59
【问题描述】：

我是Domain Pattern的新手，我需要确保我理解我到目前为止所读到的内容！！，请告诉我以下句子是否正确或不违反与DDD相关的原则

0) DAL 将在 DTO 中接收参数并在 DTO (Entity) 的 LIST 中返回获取的数据

1) 通过存储库模式解耦 BLL 和 DAL。

2) 实体是 DTO 对象。

3) ProductCategoryData 包含 ProductData 列表。

4) 如果 BLL.ProductCategory 不包含描述业务对象的属性，它将是贫血域模型 ANTI 模式。

5) BLL.ProductCategory 包含一个 BLL.Product 列表……我对此有不好的预感

6) 我在该设计中避免了贫血的领域模型反模式。

7) 我成功应用领域模型模式。

8) 我使用 DTO 对象在层之间传输数据。

请和我谈谈 :)

【问题讨论】：

【解决方案1】：

为什么会有不好的感觉？贫血听起来是个坏词，但您发现了什么危害？

我认为没有任何行为的对象是贫血的。我不根据数据成员来判断。

如果您出于其他原因选择将该行为移至其他地方（例如服务），则有一种说法是您选择的架构比面向对象更实用。真的有那么糟糕吗？

我认为像贫血这样的标签听起来很糟糕，但它们实际上只是描述了一个人的设计决定。它也可能揭示某人的 OOP 偏见。函数式语言会被 OOP 从业者认为是贫血的，但它不一定是致命的。

一个更好的问题是：“我有并行模型吗？一个用于 DTO，另一个用于业务层？”如果是，我会说双重维持比贫血更有害。

【讨论】：

我看到了一个系统，它有一个围绕 UI 传递的 DTOBLL 静态类 DAL 现在考虑一个具有 DTO.Class 的 DTO.Student，然后在某个点上，要求改变了，学生可以参加几个课程。然后我将在所有层级中更改代码，以便将 Student.Class 转换为 Student.Classes。甚至更糟糕的是，将 Student 放入 Class。

【解决方案2】：

如果这是接口并且您的对象上没有方法，那么这仍然是一个贫血模型。

存储库应与模型的聚合相关联。我的模型只包含那些实体，那么设计的好坏并不重要因为整体复杂度会很低。

还要为您的模型选择更好的名称，并避免使用“数据”等通用名称。读者马上问：什么样的数据？

【讨论】：

“如果那是接口并且你的对象上没有方法，那么这仍然是一个贫血模型。”但是我在 BLL.ProductCategory 中使用了 ListProductCategory ??
这是一个访问者而不是一个行为
所以如果我添加订阅方法，它不会贫血。但是，如果系统中的某些对象，不具有其自然行为。我很困惑？
实体总是至少有一些行为。如果他们真的没有任何行为，那么他们就是价值对象。