这是一个贫血的领域模型？

我想构建我的第一个CRUD应用程序，但我不明白我是否应该使用包含getter和setters的对象分开。这是一个贫血的领域模型？

考虑到我们有Zend Framework Quick Start tutorial含模型结构：

网关
DataMapper的
域对象（模型类）

如果域对象（如呈现在Zend快速入门教程）只包含getter和setter，是否是反模式？从某种意义上说，我们正在不断地将域对象与事务脚本分开？

请指教。

来源

2011-05-03 MEM

域对象是从软件的业务逻辑中分离出来的。这是procedural programming的重要思想。

然而，这种模式被认为是一些开发商反模式的候选人，这意味着这可能是一种无效的做法。

事实上，你可以考虑缺点

你的模型是少的表现，getter和setter方法是不是真的很好的描述模型
代码更难重用，你会得到你的事务中dublicated代码脚本
，你必须使用其隐藏实际的数据结构（所以也许不是真的OOP）
总有实体的全球访问包装

我认为最有意思的一点是，领域模型的对象无法在任何时候保证它们的正确性。因为它们的变异发生在分离的层中。

我也在使用zend框架开发CRUD应用程序。逻辑和数据之间的清晰分离真的很棒，但是当你进步的时候，你会意识到图层和映射器的数量越来越大。尝试尽可能重复使用您的代码并避免发布。

来源

2011-05-03 11:35:32

您的问题很好地阐明了：“为什么贫血区域模型是反模式”。但是它并没有回答我的问题提出的另一个问题：在表格数据网关/数据映射器设计模式上 - 就像Zend Framework快速指南教程中介绍的一样 - 我们是否也在处理反模式案例？ – MEM 2011-05-03 11:41:31

没有资源将此模式定义为反模式，至少我找不到一个模式。我指出一些开发人员将其视为反模式的候选人。所以一方面你有清楚分离的好处，另一方面也有缺点。你看到有很多“对比”，这意味着它更像是一种反模式 – 2011-05-03 11:46:10

“你的模型不那么富有表现力” - 当你建模一个CRUD应用程序时，模型不需要在获取/设置旁边表达也许有些验证。 “代码很难重用” - 再次CRUD通常很简单，并且正确的框架背后并不是一个问题。 “模型的对象不能保证它们的正确性” - 如果你期望从你的域对象得到这个，那么你需要使用DDD开始设计它们（将它们分组成集合，充当一致性边界等），在这种情况下有一个贫血域模型IS和抗百通。 – 2011-05-03 13:09:13

如果您试图构建一个真正的领域模型（也称为领域驱动设计的领域模型）并最终得到仅具有状态且没有行为的实体，那么贫血领域模型仅仅是一个反模型。

对于简单的CRUD应用程序来说，贫血区域模型可能是一种最佳实践，尤其是当您的框架使您的工作变得非常简单时。

请参阅Martin Fowler的文章Anemic Domain Model以及Greg Young's Article。

来源

2011-05-03 11:14:38

那么，我们对领域模型有两个意义？一次感觉，Zf快速教程感，告诉我们：1）领域模型（通过引用一个模型类，代表一个领域对象？）2）领域模型的领域驱动设计模式？我在问这个问题，因为在提供的链接上，你可以看到一个声明，那个getter和setter类首先被认为是“Domain Model”，后来被认为是“Domain Object”... – MEM 2011-05-03 11:35:41

对象是从模型创建的 – 2011-05-03 11:41:08

@ArtWorkAD：嗯......所以，我们不应该说：“域模型是指代表一个域对象的模型类”，但我们应该说：“域模型作为一些模型类在MVC的M部分中的类），这些类可以响应创建“域对象”。是吗？Arrrhhh !!请耐心等待:)） – MEM 2011-05-03 11:46:58

这是一个贫血的领域模型？

回答

相关问题