问题标签 [anemic-domain-model]

我通过传递要用于构造对象的数据行的主键来使用数据库表中的数据构造对象。

这个对象的成员变量的填充应该发生在构造函数中还是构造函数调用的另一个方法中，或者完全在其他地方？

这是如何在 Rails ActiveRecord 和其他 ORM 中完成的，我怀疑框架为每个字段调用了一组设置器，但我真的不想要一个复杂的框架来做这一切，所以有什么好的做法来扮演我的角色自己的简单机制？

注意：请记住，我不想创建大量无法管理自己状态的贫血数据模型。

我正在尝试构建我的第一个 CRUD 应用程序，但我不明白是否应该使用包含分离的 getter 和 setter 的对象。

考虑到我们有Zend Framework 快速入门教程，其模型结构包含：

• 网关
• 数据映射器
• 领域对象（模型类）

如果域对象（如 Zend 快速入门教程中所述）仅包含 getter 和 setter，那是一种反模式吗？从某种意义上说，我们不必要地用事务脚本划分域对象？

请指教。

如果这是重复的，我深表歉意，但我在相关问题中找不到关于该主题的任何具体示例。

在阅读了 Martin Fowler 关于“贫血域模型”的文章后，我对为什么这被认为是一种反模式感到困惑。甚至大多数企业开发人员是否认为它是一种反模式，因为 AFAIK 可能 90% 的 j2ee 应用程序都是以“贫血”的方式设计的？

有人可以推荐关于这个主题的进一步阅读（除了“领域驱动设计”这本书），或者更好的是，给出一个具体的例子来说明这种反模式如何以不好的方式影响应用程序设计。

谢谢，

这是我遇到的一个问题的简单示例，它与此处和其他地方提出的有关 DDD 的一些想法不相符。

假设我有一个创建/操纵一个人的 ASP.NET MVC 3 站点。控制器访问应用程序服务层 (PersonService)，后者又使用域实体 (EF 4 POCO) 和 PersonRepository 进行更改并持久化它们。为了简单起见，我在这里省略了所有接口。在这种情况下，Person 是根，为简单起见，只有电子邮件地址（还假设电子邮件不是不可变的并且可以更新）。

选项 1：尝试坚持 [我的理解] DDD 的基础知识，其中与实体直接相关的行为被实现为实体的一部分（Person 实现 AddEmail、ChangeEmail 等）。除了 Add* 方法之外，唯一的问题是 Person 需要了解上下文或实体框架部分（这将消除任何持久性无知）或需要使用“服务”或存储库来标记修改后的电子邮件。

选项 2：让人员服务使用存储库来添加/更新电子邮件地址，并且不对人员实体实施该行为。这在多对多关系的情况下要简单得多（例如，地址，需要更新两个表才能完成工作），但是模型变得“贫血”，只是一堆 getter 和 setter。

无论如何，对此有什么想法吗？

谢谢，布赖恩

我正在寻找一些关于我应该在多大程度上关注避免贫血域模型的建议。我们刚刚开始使用 DDD，并且正在与简单设计决策的分析瘫痪作斗争。我们坚持的最新一点是某些业务逻辑所属的地方，例如我们有一个Order对象，它具有诸如此类的属性Status。现在说我必须执行一个命令，例如UndoLastStatus因为有人在订单上犯了错误，这不是那么简单就像Status必须记录其他信息并更改属性一样更改。现在在现实世界中，这是一项纯粹的管理任务。所以我看到它的方式有两个我能想到的选择：

• 选项 1：将方法添加到 order 这样的东西Order.UndoLastStatus()，虽然这有点道理，但它并不能真正反映域。也是Order系统中的主要对象，如果涉及订单的所有内容都放在订单类中，事情可能会失控。

• 选项 2：创建一个Shop对象，该对象具有代表不同角色的不同服务。所以我可能有Shop.AdminService,Shop.DispatchService和Shop.InventoryService. 所以在这种情况下，我会有Shop.AdminService.UndoLastStatus(Order).

现在第二个选项我们有了更多反映领域的东西，并且允许开发人员与业务专家讨论实际存在的类似角色。但它也走向了贫血模型。一般来说，哪种方式更好？

以下是 JPA 注释类型层次结构，其中所有数据字段（以及相关的 getter 和 setter）都是超类型的成员以及用于实现业务逻辑的抽象方法。有许多子类型在不添加数据成员的情况下实现这些抽象方法，因此我们使用单表继承策略，因此我们只需要数据库中的一个表来支持这种类型层次结构。

我这样做是因为，根据数据的内容，必须实施不同的行为才能实现最终目标。

这是对 JPA/Hibernate 中鉴别器列概念的扭曲吗？

一位同事争辩说，由于数据的结构不会因子类型而异，因此抽象方法和相应的实现应该移动到类似于策略模式的方法中。他的想法更好吗？

我最近一直在阅读，我遇到的一件事是Martin Fowler 的这篇关于贫血域模型的文章。我知道，它很旧，但在 Java 世界中却非常实际。因此，我正在尝试转向更受领域驱动的设计。一种选择是使用 Active Record 模型。但是，我不太喜欢它在 Scala 中的当前实现。它将域对象与持久性类型完全结合起来（在大多数情况下还不错，但我有一个项目需要在 RDB 和 Mongo 中存储一些东西）。然后我看到了这篇关于 Spring、Hibernate 和 Scala的文章虽然在这里域对象也与 JPA 特征相结合，但我注意到他如何使用 Spring 来注入通知服务。不能用同样的机制注入一个透明的DAO接口吗？你见过这个用在什么地方吗？对这个想法有什么想法吗？

我正在尝试通过示例学习领域驱动设计，我需要您的建议。假设我有一个名为 Tender 的实体。我收到来自外部服务的肥皂消息；该消息包含有关投标的所有信息（tenderId，tenderSum，...）

我必须做的：

1. 使用 Soap Web Service 接收消息并将消息放入消息队列 - 由Service完成
2. 从队列中检索消息 - 由服务完成
3. 转到数据库，通过tenderId 检索一个Tender 对象或创建一个新的Tender - 由Repository完成
4. 用消息中的值填充 Tender 对象的字段 - 由Domain Object Tender完成
5. 将投标保存到数据库 - 由存储库完成

我试图以正确的方式来做，但最后我发现，大部分代码都存在于服务、存储库等中。我真的很困惑。我做错什么了？我应该在域对象中做所有这些事情吗？

在我的系统中，用户可以发布任意数量的旅行。小米用户类（域对象）是这样的

因此，如果我想获取 id = 1 的用户的所有行程：

它有效，但我认为我的 User 类存在“贫血域问题”（或贫血 POJO 问题，它是否存在？）：只有私有字段和“getter”和“setter”（我所有的 POJO 都一样）。

我想到了另一种方法：

和

使用第二种方法，用户类具有更多功能，但行程不存储在数据库中。

我错过了什么？我是 DAO 的新手，我不知道我是否采取了正确的方法。

谢谢（是的，我的英语很烂）。

ASP.NET MVC 中是否有任何使用域模型架构而不是事务脚本（服务层）架构的开源项目？我正在寻找更多的项目，然后只是小例子。