业务逻辑和数据分离，还是合二为一？

Question

4

我认为面向对象设计的基本原则是将一个类建模为代码和数据的集合。然而，在日常开发中，我倾向于将所有业务逻辑分成各自的类。数据最终以受严格控制的POCOs/DTOs存在，基本上没有实际的代码或逻辑。每当我想执行操作时，我就会实例化一个业务逻辑类并将POCOs传递给每个方法。

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

我认为我始终将这两件事分开，因为业务逻辑可能在多个POCOs上运行。另外，不强制对POCOs中的数据进行验证使其更容易进行单元测试，因为准备POCOs进行测试似乎更简单（无需担心内部类状态、封装等）。现在回顾这些原因，它们似乎很薄弱。

我正在寻找两种方法的比较/对比。特别是，为什么现在似乎制作“愚蠢”的POCOs是正确的方式？为什么不把数据和业务逻辑放到一个单一的类中呢？我们是否放弃了面向对象设计的原始目标？

谢谢！

- Brett

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- casablanca · Accepted Answer

确实，将业务逻辑与相关数据分离违反了面向对象编程的原则，这就是马丁·福勒所说的贫血领域模型。个人而言，我总是会选择一个合适的领域模型来将数据和行为放在一起。

具体来说，为什么现在制作“愚蠢”的POCO似乎是正确的方法？

我不知道你为什么会这样认为，但这显然不是真的。有很多“愚蠢”的模型存在，但也有很多设计良好的领域模型。