这是贫血领域模型吗？
我正在尝试构建我的第一个 CRUD 应用程序，但我不明白是否应该使用包含分离的 getter 和 setter 的对象。
考虑到我们有 Zend Framework 快速入门教程模型结构包含：
- Gateway
- DataMapper
- 域对象（模型类）
如果域对象（如 Zend 快速入门教程中所示）仅包含 getter 和 setter，这是反模式吗？从某种意义上说，我们不必要地用事务脚本来划分领域对象？
请指教。
I'm trying to build my first CRUD application, and I don't understand if I should use an object containing getters and setters separated.
Considering that we have the Zend Framework Quick Start tutorial with a Model structure containing:
- Gateway
- DataMapper
- Domain Object (model class)
If the Domain Object (as presented on Zend Quick Start Tutorial) consists of only getters and setters, is that an anti-pattern? In a sense, we are unecessarily dividing the domain object with a transaction script?
Please advise.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅当您尝试构建真正的领域模型（又名领域驱动设计中的领域模型）并最终得到只有状态而没有行为的实体时，贫乏领域模型才是反模式。
对于简单的 CRUD 应用程序，贫血域模型可能是最佳实践，尤其是当您拥有使您的工作变得非常轻松的框架时。
请参阅 Martin Fowler 关于 贫血域模型 的文章以及 Greg Young 的文章。
The Anemic Domain Model is an Anti-Patern ONLY IF you are trying to build a true Domain Model (aka Domain Model from Domain Driven Design) and end up with entities with only state and without behavior.
For a simple CRUD application an anemic domain model is probably a best practice, especially when you have framework that makes your job very easy.
See Martin Fowler's article about Anemic Domain Model and also Greg Young's Article.
领域对象与软件的业务逻辑分离。这是过程式编程的一个重要思想。
然而，这种模式被一些开发人员认为是反模式的候选者，这意味着它可能是一种无效的实践。
事实上，您可以考虑缺点，
我认为最有趣的一点是域模型的对象不能保证它们在任何时候的正确性。因为它们的突变发生在不同的层中。
我也使用 zend 框架开发了 CRUD 应用程序。逻辑和数据之间的清晰分离确实很棒，但是当您取得进展时，您会意识到图层和映射器的数量变得越来越大。尝试尽可能多地重用您的代码并避免重复。
The domain objects are seperated from the business logic of the software. This is an important idea of procedural programming.
However this pattern is considered to be a candidate for an anti-pattern by some developers which means that it might be a ineffective practice.
In fact you could consider disadvantages
I think the most interesting point to consider is that domain model's objects cannot assure their correctness at any time. Because their mutation takes place in seperated layers.
I worked on a CRUD application with zend framework too. The clear separation between logic and data is really great but when you progress you realize that the amount of layers and mappers gets bigger and bigger. Try to reuse your code as much as you can and avoid dublication.