贫血模型

最近的一些项目中，我使用的都是所谓的贫血模型（Martin Fowler提出的），什么是贫血模型，也就是说在Domain Mode中仅仅是get set方法，没有业务逻辑（Business Logic）。我现在的项目就是使用这种贫血模型+事务脚本（Transaction Script）实现的。我们可以看看Martin对事务脚本模式的描述：从表示层获得输入、进行校验和计算处理、将数据存储到数据库中、以及调用其他系统的操作等。然后该过程将更多的数据返回给表示层、中间可能要进行大量的计算来组织和整理返回值。基本的组织方式是让每一个过程对应用户可能的做的一个动作。事务脚本的优点：它是一个大多数开发者能够理解的简单过程模型。它能够与一个使用行数据入口或表数据入口的简单数据源层很好的协作。设定事务的边界方法很容易确定。缺点就是当业务逻辑很复杂的时候，若干事务需要做相似的操作时，通常使多个事务中包含某些相同的代码。如果抽去这些代码，应用程序就会没有清晰的结构，繁杂不堪。
对于上面的描述我也深有体会，但是现在为什么还在用所谓的贫血模型，而不采用所谓的Rich Domain Model。原因就在于结构繁琐，但是现在有了一些OR映射的工具（JDO Hibernate等），对于DAO部分的操作应该比较容易处理，而且职责更加明确，接口深度更深。针对OR工具已经做好的工作，我们就不再需要做了，要做的就是业务逻辑的处理。Martin提出的Rich Domain Model中应该带有一定的逻辑方法，这就是新的矛盾，就是DM中的业务逻辑方法同业务逻辑类中的方法职责如何划分。一个原则就是：同DM属性关系紧密地业务逻辑放在DM中。其余的放在业务逻辑类中。
简单的领域模型有可能和数据库的设计很相似，而复杂的就可能用到继承、策略和其他设计模式，是一张由互联的细粒度对象组成的复杂网络。复杂的领域模型更适合于复杂的业务逻辑，但他映射到数据库更加困难，所以最好有OR工具。