oop - 业务逻辑加数据，还是两者分开？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




我的理解是 OO 设计的基本原则是，人们应该专注于将类建模为代码和数据的联合。然而，在日常开发中，我倾向于将我所有的业务逻辑分成它们自己的类。 “数据”最终位于严格控制的 POCO/DTO 中，基本上没有真正的代码或逻辑。然后我实例化一个业务逻辑类，并在我希望操作发生时将 POCO 传递给每个方法。

但这感觉像是两种不同的方法。事实上，后一种方法似乎与 OO 的目的不一致!

我想我一直将这两件事分开，因为业务逻辑可能会在多个 POCO 上运行。另外，不强制验证 POCO 中的数据使得单元测试更容易，因为为测试准备 POCO 似乎更简单(无需担心内部类状态、封装等)。现在回想这些原因，它们似乎很弱。

我正在寻找两种方法的比较/对比。具体来说，为什么现在制作“愚蠢”的 POCO 似乎是要走的路？为什么不将数据和业务逻辑放在一个类中？我们是否放弃了面向对象设计的最初目标？

谢谢!

Answer 1

实际上，将业务逻辑与关联数据分离是违反 OOP 原则的，这就是 Martin Fowler 所说的 anemic domain model .就我个人而言，我总是会使用一个合适的域模型，将数据和行为放在一起。

Specifically, why does it seem that making 'dumb' POCOs is the way to go these days?

我不知道你为什么这么认为，但这肯定不是真的。有许多“愚蠢”的模型，但也有许多精心设计的领域模型。