了解DTO和贫血域模型

我是新来的域模式，我需要确保我明白我迄今为止阅读过的内容!!，请告诉我以下句子是否为真或者是否违反了与DDD了解DTO和贫血域模型

enter image description here

0）DAL将在DTO接收参数和在DTO（实体的列表中返回取的数据）

1）去耦合BLL和DAL通过库的图案。

2）实体是DTO对象。

3）ProductCategoryData包含ProductData的列表。

4）如果BLL.ProductCategory不包含描述业务对象的属性，它将成为Anemic Domain Model ANTI Pattern。

5）BLL.ProductCategory包含BLL.Product的名单......我有不好的感觉，这

6）我避免在设计贫血域模型反模式。

7）我成功应用了域模型模式。

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

请跟我说说:)

来源

2011-06-21 Costa

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

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

也为您的模型选择更好的名称，并避免通用名称，如“数据”。读者立即问：什么样的数据？

来源

2011-06-21 16:20:42 fabrizioM

“如果这是界面，并且对象上没有方法，那么这仍然是一个贫血模型。” 但我在BLL.ProductCategory中使用了ListProductCategory ?? – Costa

这是一个访问者不是行为 – fabrizioM

所以，如果我添加Susbscribe方法，它不会贫血。但是，如果系统中的某些对象没有按其自然行为进行操作。我很困惑？ – Costa

为什么你有一种不好的感觉？贫血症听起来像一个不好的字，但是你发现了什么危害？

我看到的对象没有任何贫血行为。我不会被数据成员判断。

如果您选择其他原因将此行为转移到其他地方（例如服务），则有一种说法认为您选择的功能比面向对象的功能更强。这真的很糟糕吗？

我认为像贫血这样的标签听起来很糟糕，但它们只是描述一个人的设计决定。它也可能揭示某人的面向对象的偏见。功能语言会被OOP从业者视为贫血症，但并不一定是致命的。

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

来源

2011-06-21 16:12:57 duffymo

我看到了一个系统，具有DTO的传来传去 UI <-> BLL静态类<-> DAL 现在考虑DTO.Student具有DTO.Class，然后在某一点上，要求改变，学生可以参加几个班。然后，我将有代码在所有层次中进行更改，以便将Student.Class转换为Student.Classes。，或者通过将Students放入Class中，甚至更糟糕。 – Costa

了解DTO和贫血域模型

回答

相关问题