问题标签 [anemic-domain-model]

我在一个非常重视单一职责原则的项目中。我们有很多小班，事情很简单。然而，我们有一个贫乏的领域模型——在我们的任何模型类中都没有行为，它们只是属性包。这不是对我们设计的抱怨——它实际上似乎工作得很好

在设计评审期间，每当向系统添加新行为时，都会引入 SRP，因此新行为通常会在新类中结束。这使事情很容易进行单元测试，但有时我会感到困惑，因为感觉就像将行为从相关的地方拉出来。

我正在努力提高我对如何正确应用 SRP 的理解。在我看来，SRP 反对将共享相同上下文的业务建模行为添加到一个对象，因为该对象不可避免地最终要么做不止一件相关的事情，要么做一件事但知道改变形状的多个业务规则其输出。

如果是这样，那么感觉最终结果是一个贫血域模型，这在我们的项目中肯定是这种情况。然而，贫血域模型是一种反模式。

这两种想法可以共存吗？

编辑：几个与上下文相关的链接：

SRP - http://www.objectmentor.com/resources/articles/srp.pdf
贫血域模型 - http://martinfowler.com/bliki/AnemicDomainModel.html

我不是那种只喜欢寻找先知并遵循他们所说的福音的开发人员。因此，我不提供这些链接作为说明“这些是规则”的一种方式，只是作为这两个概念定义的来源。

在阅读了这个反模式以及关于它的许多担忧之后再次感到困惑。

如果我有一个域模型并捕获必须保存在数据传输对象中的数据，这是否会使我的域模型成为数据的包装器？在那种情况下，我将使用贫血域模型。但是，如果我在该包装器上添加足够的域逻辑，那么它在什么时候成为真正的域模型呢？

我的印象是，捕获必须在域模型中保留的内容违反了良好实践，并创建了贫乏的域模型反模式。但是，如果您使用关系数据库，则无法避免挑选出构成对象状态的部分并保存它。

因为我对这些概念很困惑，所以我不确定我写的东西是否有意义。随时要求澄清。

如果您的应用程序是这样的，是否可以使用 DDD 和富域模型：

• 窗口客户端 (WPF)
• 窗口服务

与 WCF 进行通信？

我习惯于只有数据状态的 DTO，并且在服务层中有业务规则，但每个人都一直告诉我，我应该有一个丰富的域模型，其中数据状态和规则/方法都在对象本身中。

我只是不确定这个富域模型是否适用于具有 UI 并通过 WCF 与服务通信的系统（就像我上面介绍的那样）。就我而言，由于 WCF，继续使用贫血域模型会更好吗？如果没有，您能否举例说明如何使用富域模型构建它，考虑 WCF、代理等？

谢谢！

我们当前的 O/RM 工具并不能真正支持丰富的领域模型，因此我们不得不在任何地方都使用贫血 (DTO) 实体。这工作得很好，但我继续为将基本的基于对象的业务逻辑和计算字段放在哪里而苦苦挣扎。

当前层：

• 介绍
• 服务
• 存储库
• 数据/实体

我们的存储层具有大部分基本的获取/验证/保存逻辑，尽管服务层做了很多更复杂的验证和保存（因为保存操作也做日志记录、权限检查等）。问题是在哪里放置这样的代码：

或者

有什么想法吗？

哪些指标可以帮助表明我有过程代码而不是面向对象的代码？我想要一组简单的指标，这些指标很有可能表明分析的代码包含过程事务脚本和贫乏的域模型，而不是遵循健全的面向对象设计原则。

对任何有用的衡量指标和工具集都会感到高兴。

谢谢，托马斯！

我试图了解贫血域模型以及为什么它们被认为是反模式。

这是一个真实世界的例子。

我有一个 Employee 类，它有很多属性——姓名、性别、用户名等

接下来，我们有一个系统，该系统涉及在销售人员之间平均轮换来电和网站查询（称为“潜在客户”）。这个系统相当复杂，因为它涉及轮询查询、检查假期、员工偏好等。所以这个系统目前被分离成一个服务：EmployeeLeadRotationService。

然后在我们网站查询表的背面，我们有这样的代码：

这种方法我并没有真正遇到很多问题，但据说这是我应该尖叫的东西，因为它是一个贫血域模型。

但对我来说，不清楚铅轮换服务的逻辑应该去哪里。它应该领先吗？它应该进入员工吗？

轮换服务需要的所有注入的存储库等怎么样 - 考虑到大多数时候与员工打交道时我们不需要任何这些存储库，它们将如何注入员工？

根据您的经验，贫血域模型的优缺点是什么？尽管 wiki 说了什么。

更新：我正在寻找基于这种模式在大型企业应用程序中应用的经验的答案！

在 Entity Framework 中，是否可以让框架将 DbContext 注入到每个附加到 Context 或从 Context 检索的对象（实体）中？

我是一个 NHibernate 人，我知道在 NH 中这是可能的，如果这是 EF 世界中的一个愚蠢问题，我很抱歉。

本质上，我希望我的一些实体具有 DbContext 类型的属性，每当我将实体与上下文相关联时，框架本身都会将其设置为上下文的实例。理想情况下，此类类将使用 IContextAware 标记接口或类似的东西进行标记。

我想这样做的原因是（=目标），这次我想避免贫血域模型反模式。我想如果我将 ObjectContext 注入实体，它们将能够访问 DB，从而允许我在域类本身内部实现查询和更复杂的逻辑。如果您知道实现我的目标的其他方法（尤其是在网络应用程序的上下文中），请这样做，但请尽量避免诸如“您不应该这样做，因为”之类的答案。谢谢！！！

由于 Java EE 世界的新改进导致大量设计模式被弃用，DTO 在很大程度上受到了反对。

但是，我不希望数据库的关系结构决定客户端（Web 应用程序）如何使用我的 EJB 中的服务。由于技术的发展方式，我看到在大约 5 年的时间里，随着光纤技术和其他不可思议的技术成为现实，我看到了试图彻底改革 UI 的工作。所以我希望业务逻辑被完全封装，以便我们可以随时轻松更改 UI。

考虑到这种想法，我正在开发一个纯 API 来表示业务模型和服务，以便客户可以使用它。

但是，我不得不一直编写转换器来将实体 bean 转换为这个 API。这是正确的做法还是过度工程。

您的反馈和意见在很大程度上受到欢迎。

注意。该项目使用完整的 Java EE 6 平台

去年左右我一直在学习 C#，并尝试在此过程中整合最佳实践。在 StackOverflow 和其他网络资源之间，我认为我在正确分离我的关注点方面处于正确的轨道上，但现在我有一些疑问，并想确保在我将整个网站转换到这个新网站之前我走的是正确的道路建筑学。

当前的网站是旧的 ASP VBscript，并且现有的数据库非常丑陋（没有外键等），因此至少对于 .NET 中的第一个版本，我不想使用并且必须学习任何 ORM 工具。

我有以下项目，它们位于单独的命名空间和设置中，因此 UI 层只能看到 DTO 和业务层，而数据层只能从业务层看到。这是一个简单的例子：

产品DTO.cs

产品BLL.cs

产品DAL.cs

在我的 UI 中，我会做这样的事情：

为了节省：

我完全不在基地吗？我是否应该在我的 BLL 中也有相同的属性并且不将 DTO 传递回我的 UI？请告诉我什么是错的，什么是对的。请记住，我还不是专家。

我想为我的架构实现接口，但我仍在学习如何做到这一点。