问题标签 [anemic-domain-model]

基于这个答案，我发现贫血域模型背后的相同想法正在积极记录中！在活动记录模式中，数据库字段与域属性相同（如果我错了，请纠正我），所以根据我之前提到的答案，我们在贫血模型中也有相同的（很容易从数据库表中自动生成），那又如何这两种方法有什么区别？谢谢

我不太清楚应该如何设计一个类：

• 贫血模型域状态：

这种反模式的根本可怕之处在于它与面向对象设计的基本思想背道而驰。也就是将数据组合起来并一起处理。贫血域模型只是一种程序化风格设计，正是像我这样的对象偏执狂……从我们在 Smalltalk 的早期开始就一直在争取的东西。更糟糕的是，许多人认为贫血的对象是真实的对象，因此完全忽略了面向对象设计的意义所在。在贫乏的领域设计中，业务逻辑通常在单独的类中实现，这些类会转换领域对象的状态。Fowler 调用此类外部类事务脚本。这种模式是 Java 应用程序中的一种常见方法，可能受到早期版本的 EJB 实体 Bean 等技术的鼓励，以及在遵循三层服务应用程序架构的 .NET 应用程序中，其中此类对象属于“业务实体”类别

• DTO（数据传输对象）

数据传输对象与业务对象或数据访问对象之间的区别在于，DTO 除了存储和检索自己的数据（访问器和修改器）之外没有任何行为。DTO 是简单的对象，不应包含任何需要测试的业务逻辑。

• 活动记录模式

参考维基百科

• 现在还要参考这个问答：如何调用也访问数据库的 DTO 类？

似乎DTO 应该只用于在 web 服务之间共享数据，但同时，意识到它们在 DB 上的持久性的 Active Record 也很糟糕。

那么应该在包含从数据库中获取的数据的类中放入哪种逻辑？

我对整个 .NET 场景还很陌生，我仍在努力解决这个问题。

似乎非常提倡的一件事是领域驱动设计模式。尽管我渴望在 .NET 世界中取得飞速发展并正确地做到这一点，但我潜心尝试将其应用到我的项目中。

据我了解，让域对象访问诸如存储库之类的持久层功能是一种不好的做法，但是我真的在努力解决在使用高度连接的图时如何解决急切加载的问题。它通常最终在域模型中几乎没有逻辑，并将所有逻辑移动到服务层，该服务层进行计算并用数据填充模型对象或直接返回结果，price = productService.CalculatePriceFor(product, user);而不是price = product.Price(user)因为后者无法完成首次请求对象时急切加载整个产品组树和折扣矩阵。

这里有什么好的做法？实现产品的子类，其中获取用户价格的信息是在加载时计算的，并且当我不需要用户价格时有另一个子类？

我正在决定是否应该使用富域模型而不是贫血域模型，并寻找两者的好例子。

我一直在使用贫血域模型构建 Web 应用程序，由服务 --> 存储库 --> 存储层系统支持，使用FluentValidation进行 BL 验证，并将我的所有 BL 放在服务层中。

我读过 Eric Evan 的 DDD 书，他（连同 Fowler 和其他人）似乎认为贫血域模型是一种反模式。

所以我真的很想深入了解这个问题。

此外，我真的在寻找富域模型的一些好的（基本）示例，以及它提供的贫血域模型的好处。

我试图找到一个清晰而简单的例子来说明贫血域的真正含义。周围有很多理论，也有很多很好回答的问题。尽管如此，我仍然无法清楚地了解“贫血领域”的含义究竟在多大程度上。因此，我相信看到一个贫血域设计的虚拟实际示例会更简单，而不是问你如何将其演变为域驱动的设计......

所以，假设我们有一个TaskData类型的数据实体：

并且需要一个名为“ ActualState ”的附加属性，它是一个计算状态：如果 Task 有内部子任务，则值严格取决于子任务，否则，“ ActualState ”等于“ ExplicitState ”

如果我在一个单独的服务类（我称之为“引擎”）中编写这个逻辑，我们有：

第一个问题是：

即使TaskStateCalculator服务/引擎是我的域层的一部分，上面的代码是否反映了贫乏的域设计？如果是，为了避免这种情况，我们需要移动TaskData类中的逻辑（并将TaskData重命名为Task）。我对吗？

第二个问题是（实际上是一连串）：

如果我们遇到更困难的情况怎么办？假设在Task实体中需要一个名为ComputeSomething的属性，并且该属性的逻辑需要访问整个 Task 的存储库。在这种情况下，Task类将依赖于TaskRepository。这样可以吗？EF 如何构造此类的实例？什么是替代方案？

We are planning to developing a software following Domain Driven Design inspiring by the Red (EE) and Blue (VV) ddd books. The business is not that complicated. It is possible to avoid inheritances for all concrete classes. The goal is to feel the importance of Domain Model. So is it OK to use POCO classes which will be inherited from Entity? Or It will be better to create the domain model and use DTO or repository to transfer values to domain model?

我试图深入了解 DDD，并阅读了 Eric Evans 关于域驱动设计的书和 Julie Lerman 的博客，他们描述：

Anemic Domain Model作为具有专注于状态管理的类的模型。适合 CRUD。

Entity作为具有用于跟踪和持久性的标识的可变类。

当然两者都用于相同的目的，或者我完全搞错了？两者有什么区别？我读过贫血的域模型通常用于表示数据库模式，但对于实体来说也不一样吗？

例如，一个table被调用的 Customer 具有：

根据我的理解anemic domain model，表示这看起来像：

对我来说，过去的经验表明，一个实体也可以以这种方式用一系列属性来表示getter，setter一个实体框架？两个概念（实体和贫血域模型）都是mutable？

谢谢，DS。

我收到了几十条旧 SQL 语句，每条语句都有数百行。Models每个 SQL 都映射到共享项目中具有自己唯一 POCO 的代码。

例如项目中的 SQLSelect Name, Birthday From People有一个等价的 POCO Models：

在我的 DAL 中，我有一个通用SQL运行器，它<T>代表 SQL 的 POCO。所以我的业务逻辑可以调用GetSqlResult<BirthdayPerson>()：

问题是我的Models库在整个应用程序中使用，并且我不希望 SQL 在该 HardcodedSql 属性中的应用程序中公开。

这是我正在使用的架构：

我对 OOP 中的贫血域模型有点困惑。是一种普通的旧 X 对象包（其中 X 代表您喜欢的语言），没有行为（和责任）。

...所有逻辑都在某些服务中？

这出现在Martin Fowler的AnemicDomainModel文章的末尾

通常，您在服务中发现的行为越多，您就越有可能剥夺自己从领域模型中获得的好处。如果您的所有逻辑都在服务中，那么您已经蒙蔽了自己。

这意味着什么？最好使用智能对象而不是智能服务。

我正在编写一个考虑到 DDD 的应用程序，并试图通过将域逻辑和行为委托给实体来避免出现贫血的域模型。在构建作为聚合根的实体并且需要创建需要由工厂类处理的子实体时，我遇到了一个问题。这是一个例子：

我有以下实体Page：Url和Layout。使我的模型中的 Page 是PageaUrl和 a Layout- 没有这两个，Page对象将无效。在一个简单的模型中，Page构造方法将简单地将这两个对象创建为私有属性。但是，Url有一个特定的要求；它必须从页面的标题（或 slug）创建，并且必须是唯一的（通过附加“-1”、“-2”或类似的东西来确保）。这需要与存储库进行通信。

我最初的想法是将UrlFactory对象传递/注入到Page构造函数并Page创建Url它需要的对象，但我一直在阅读有关如何将服务注入实体是一个坏主意的信息。

所以，我的问题是；有没有一种方法——或一种既定的模式——允许实体在没有贫乏的域模型的情况下构建其复杂的子实体，或者在这种情况下注入工厂是一种有效的解决方案？