贫血、充血模型的解释

名称	特征	实现举例	说明	优缺点
失血模型	1、domain object只有属性的getter/setter方法的纯数据类 2、所有的业务逻辑完全由business object来完成	ItemDao类：接口类，持久化操作的接口都放在这里 ItemDaoHibernateImpl类：ItemDao的实现类，完成具体的持久化工作 ItemManager类：实现具体的业务逻辑 Item类：纯数据类，只有getter/setter方法	这种模型下的domain object被Martin Fowler称之为“贫血的domain object”
贫血模型	1、domain object包含了不依赖于持久化的领域逻辑 2、那些依赖持久化的领域逻辑被分离到Service层	ItemDao类：接口类，持久化操作的接口都放在这里 ItemDaoHibernateImpl类：ItemDao的实现类，完成具体的持久化工作 ItemManager类：实现具体的业务逻辑 Item类：带有业务逻辑的实体类，不能依赖ItemDao	1、这种模型是Martin Fowler所指的真正的domain model 2、业务逻辑切分原则： 可重用度高的，和domain object状态密切关联的放在Item中。 可重用度低的，和domain object没有密切关联的放在ItemManager中。 3、domain object：可以脱离持久层框架进行单元测试，这个domain object是一个完备的，自包含的，不依赖于外部环境的领域对象，这种情况下，这个logic才是domain logic	优点： 各层单向依赖，结构清楚，易于实现和维护 设计简单易行，底层模型非常稳定。 缺点： domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO。 Service层过于厚重。
充血模型	1、绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑) 2、Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道 3、这种模型就是把第二种模型的domain object和business object合二为一了	多了个Service类，提供外部交互的api ItemDao类：接口类，持久化操作的接口都放在这里 ItemDaoHibernateImpl类：ItemDao的实现类，完成具体的持久化工作 Item类：即包含实体类信息，也包含所有的业务逻辑		优点： 更近符合OO Service层很薄，只充当Facade的角色，不和Dao打交道 缺点： Dao和domain object形成了双向依赖，可能导致很多潜在的问题 Service层和Domain层的逻辑划分，因为没有清晰的边界，可能导致整个结构的混乱 考虑到Service层的事物封装特性，Service层基本重定义了一遍所有的domain object，变为了过程式的Service TransactionScript。从web层看和贫血模型没什么区别。
胀血模型	1、直接取消Service层，在domain object的domain logic上面封装事务	ItemDao类：接口类，持久化操作的接口都放在这里 ItemDaoHibernateImpl类：ItemDao的实现类，完成具体的持久化工作 Item类：即包含实体类信息，也包含所有的业务逻辑		优点： 简化了分层； 更符合OO 缺点： Service逻辑强行放到domain object，引起了domain object模型的不稳定 domain object暴露给web层过多的信息，可能引起意想不到的副作用

参考： 

贫血，充血模型的解释以及一些经验_知识库_博客园