1

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

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

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

参考维基百科

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

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

4

2 回答 2

1

让我们弄清楚一些概念：

  • 领域模型：是包含业务规则的模型。它由代表业务及其流程使用的概念的对象组成。

  • DTO：顾名思义，数据传输对象是一种将数据从/向域模型传递的方式。DTO 在应用程序的不同层有多种用途：

    • 资源：是否从 RESTful API 返回 DTO。

    • DAO：DTO 是发送到持久层还是从持久层返回。

    • 视图模型：DTO 是否发送到表示层上的视图并从其返回。

所以你看，DTO 是一个非常笼统的概念，它在应用程序中以多种方式实现。

领域模型由业务对象（也称为领域对象）组成。它不是由 DTO 组成的。

这些对象必须强制执行业务规则并通过公开方法来做到这一点。如果您将这些规则放在其他地方，则域对象必须公开其内部数据（实际上成为 DTO），因此包含逻辑的对象可以处理它。

经验证明，这更难维护和更改以适应未来的需求。这也违背了 OOP 原则。这就是为什么它被认为是一种反模式，甚至被命名为：贫血域模型。

于 2018-12-05T00:04:54.877 回答
0

您应该拥有自己的域实体。您可以在持久层中使用 Active Record。将其视为一个没有任何功能的数据库表，只是从数据库中保存和检索对象。然后，您可以拥有使用 AR 中的数据创建域实体的工厂。现在您可以自由地使用多态性、设计模式并将 oop 原则应用于您的域实体。

这个想法不是将逻辑放入 AR 类中。使用它们只是因为您不想编写直接的 SQL 查询。

用户 AR 映射到用户表，但工厂可以根据该数据构建订阅者或用户。我在这篇博文中写了一些关于此的内容：http: //thesolidphp.com/reducing-code-complexity-through-good-design/

于 2014-10-15T18:06:15.777 回答