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

Question

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

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

我认为我总是把这两件事分开，因为业务逻辑可以在多个POCO上运行。另外，不强制对POCO中的数据进行验证使得单元测试更容易，因为为测试准备POCO似乎更简单（无需担心内部类状态，封装等）。既然我正在回顾这些原因，那么它们似乎很脆弱。

我正在寻找这两种方法的比较/对比。具体来说，为什么这些日子让“笨蛋”POCO成为可行的方式呢？为什么不将数据和业务逻辑粘贴到一个类中？我们是否放弃了面向对象设计的最初目标？

谢谢！

Answer 1

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

  

具体来说，为什么看起来制作'哑巴'的POCO是最近走的路？

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