是否应该让实体类具备丰富的业务逻辑？

希望大家讨论都结合自己的实践经验来谈论，不要高来高去的堆砌专业词汇，不要搞成一场引经据典的语文修辞比赛！

在这里我们不相信权威，我们只相信实践

昨天就看到了 “Hibernate实体类 == 领域模型 ？ ” 这篇帖子，http://forum.iteye.com/viewtopic.php?t=11608&highlight= 。 看到今天的题目，就更明确了。



首先，表明一下立场，我是第二种方式的支持者，也就是说“实体类”里应该加入业务逻辑。



“实体类”这个称谓，感觉不是很好，因为它实际已经限制住了它的作用范围，做为“实体”，它更应该是和数据库相关的，更应该是没有业务逻辑的。MartinFowler所说的DomainModel，不应该是所谓的“实体”，DM更应该是业务层中的一部分。



举一个具体的例子吧，看看大家如何解决，无论是用 DM 还是用 实体：



在财务和金融行业的业务中，最常见的一个概念，就是金额，它几乎会出现在任何一张业务单据中，而金额这个概念，除了具体数值外，还会存在汇率，原币，本币，外币金额等相关数据。而对于金额的业务操作则会涉及到 加， 减 ，求平均值，金额折算 等相关的一些业务操作。


金额 ： { 发生金额 ， 发生币种 ， 原币金额 ， 原币币种 ， 本币金额 ， 折原汇率 ， 折本汇率 }


由于金额几乎在每种类型的业务单据中都会出现，因此，也就是说，几乎每张业务单据的数据表上，都会存在着 上面所罗列的若干字段，甚至是倍数。 如果是用 实体 ＋ Service 的方式，就一定会写一个 金额 Service 的这个东西。 如果纯粹从面向对象的角度来讲，这究竟是不是指责单一呢？我不觉得是，这让我仿佛又回到了 C 的年代， 数据 + 过程。


由于实际业务中， 金额 可能并不一定会有 上面所有的字段，也或者可能更多，因此，金额 实际也会有自身的集成结构体系的。


比如 ： 在 分账财务 中 ， 金额 ： { 发生金额 ，发生币种 ， 原币金额 ，原币币种 ， 折原汇率 }
在 统账财务 中 ， 金额 ： { 发生金额 ， 发生币种 ， 原币金额 ， 原币币种 ， 本币金额 ， 折原汇率 ， 折本汇率 }
在 非核算业务 中， 金额 ： {发生金额 ， 发生币种}

对应这这种继承体系，同样，我们也要维护一套 金额 Service 的继承体系，这是否也是职责单一呢？是否更利于维护和扩展呢？


在不贫血的DM中，金额可以被认为是一种业务的元数据，具体的实现则可以表示为值对象（ValueObject），就像是 Numberic / Integer / BigDecimal 这样的结构一样。在分析模式或者其它的一些经典的业务建模书籍中，都可以找到具体的设计和实现。

如果把 BigDecimal 这样的类，也分为 数据实体和Service ，是否有些感觉诡异呢？



大概这样吧，不知道说的清楚不清楚，我只想通过这个例子表明，DomainModel 或者可以表示为 实体 ＋ Service ，但这觉不是 DomainModel 最佳的实现方式，同时这也不是符合上面大家都在提到的职责单一原则的，恰恰相反，它破坏了对一个整体概念的封装。

很精辟！ 第一种方式，很容易陷入过程式的开发。
不过现在国内绝大多数的应用都是Transaction Script 模式的，这个本应该是缺点的东西反而已经逐渐变为“优点”了。 正如Robbin说的“分离关注点”，不过和 在Action或者Service中，为实现某一业务逻辑，频繁调用不同Service暴露的方法，这也不应该成为分离关注点的结果吧！ 更甚的是，某几个业务逻辑 可能 一部分代码是重复的，这似乎也是顺期而然的事情！    

看看这个例子：

老实说，我觉得你们对第一种模型（即所谓贫血模型）理解有误，你们认为实体类就是只有getter/setter方法的数据类，这是误解。就你画出来的这个UML类图来说，即使在第一种模型中，这些方法也是必须放在实体类内部的。