了解 DTO 和贫血域模型
我是领域模式的新手，我需要确保我理解到目前为止所读到的内容！！，请告诉我以下句子是否正确或没有违反与 DDD 相关的原则
0) DAL 将接收 DTO 中的参数并在 DTO（实体）的 LIST 中返回获取的数据
1) 解耦BLL 和 DAL 通过存储库模式。
2）实体是DTO对象。
3) ProductCategoryData 包含 ProductData 列表。
4) 如果 BLL.ProductCategory 不包含描述业务对象的属性，则它将是贫血域模型 ANTI 模式。
5) BLL.ProductCategory 包含 BLL.Product 列表……我对此有不好的预感
6) 我在设计中避免贫血领域模型反模式。
7）我成功应用了领域模型模式。
8）我使用DTO对象在层之间传输数据。
请与我交谈:)
I am new to Domain Pattern, I need to ensure that I understand what I had read so far!!, Please tell me whether the following sentences are true or did not violate a principle related to DDD
0) DAL will receive parameters in DTO and return fetched data in LIST of DTO (Entity)
1) De-couple BLL and DAL through repository pattern.
2) Entity is DTO object.
3) ProductCategoryData contains a list of ProductData.
4) It will be Anemic Domain Model ANTI Pattern if BLL.ProductCategory does not contain properties that describe the business object.
5) BLL.ProductCategory contains a List of BLL.Product……I have bad feeling about this
6) I avoid in that design anemic domain model anti pattern.
7) I successfully Apply Domain Model Pattern.
8) I used DTO objects to transfer data between tiers.
Please talk to me :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么你有不好的预感？贫血听起来是个坏词，但你发现了什么危害呢？
我认为没有任何行为的物体是贫血的。我不根据数据成员来判断。
如果您出于其他原因选择将该行为转移到其他地方（例如服务），则有人认为您选择的架构比面向对象的架构更实用。真的有那么糟糕吗？
我认为像贫血这样的标签听起来很糟糕，但它们实际上只是描述了一个人的设计决策。它还可能揭示某人的 OOP 偏见。函数式语言会被 OOP 从业者认为是贫血的，但这并不一定是致命的。
一个更好的问题是：“我有并行模型吗？一个用于 DTO，另一个用于业务层？”如果是的话，我想说双重保养的危害远比贫血大。
Why do you have a bad feeling? Anemic sounds like a bad word, but what harm have you detected?
I see objects that don't have any behavior as anemic. I don't judge by data members.
If you choose for other reasons to move that behavior somewhere else (e.g. services), there's an argument that you're choosing an architecture that's more functional than object-oriented. Is that really so bad?
I think labels like anemic can sound bad, but they really just describe one person's design decision. It might also reveal someone's OOP bias. A functional language would be considered anemic by an OOP practitioner, but it's not necessarily fatal.
A better question to ask is: "Do I have parallel models? One for DTO and another for business layer?" If yes, I'd say that dual maintenance is far more harmful than anemia.
如果这就是接口，并且您的对象上没有方法，那么这仍然是一个贫乏的模型。
存储库应该与模型的聚合相关联。
如果你的模型只包含这些实体，那么设计的好坏并不重要
因为整体复杂度会很低。
还要为您的模型选择更好的名称，并避免使用“数据”等通用名称。
读者立即问：什么样的数据？
If that is the interface and there are no methods on your objects then that is still an anemic model.
The Repository should be associate to the aggregates of the model.
I your model only contains those entities then does not really matter how bad or good the design is
because the overall complexity will be low.
Also choose better names for your model, and avoid generic names like "Data".
The reader immediately asks: what kind of data ?