模型包括：
1，失血模型
2，贫血模型
3，充血模型
4，胀血模型
一、失血模型：
失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。
一个实体类叫做Item，指的是一个拍卖项目
一个DAO接口类叫做ItemDao
一个DAO接口实现类叫做ItemDaoHibernateImpl
一个业务逻辑类叫做ItemManager(或者叫做ItemService)
二.贫血模型： 就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。Service(业务逻辑，事务封装) --> DAO ---> domain object
这也就是Martin Fowler指的rich domain object
一个带有业务逻辑的实体类，即domain object是Item
一个DAO接口ItemDao
一个DAO实现ItemDaoHibernateImpl
一个业务逻辑对象ItemManager
这种模型的优点：
1、各层单向依赖，结构清楚，易于实现和维护
2、设计简单易行，底层模型非常稳定
这种模型的缺点：
1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO
2、Service层过于厚重
三、充血模型
充血模型和第二种模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑)
，而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道。
Service(事务封装) ---> domain object <---> DAO
这种模型就是把第二种模型的domain object和business object合二为一了。所以ItemManager就不需要了，在这种模型下面，只有三个类，他们分别是：
Item：包含了实体类信息，也包含了所有的业务逻辑
ItemDao：持久化DAO接口类
ItemDaoHibernateImpl：DAO接口的实现类
这种模型的优点：
1、更加符合OO的原则
2、Service层很薄，只充当Facade的角色，不和DAO打交道。
这种模型的缺点：
1、DAO和domain object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。
2、如何划分Service层逻辑和domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。
3、考虑到Service层的事务封装特性，Service层必须对所有的domain object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义
四、胀血模型
基于充血模型的第三个缺点，有同学提出，干脆取消Service层，只剩下domain object和DAO两层，在domain object的domain logic上面封装
事务。
domain object(事务封装，业务逻辑) <---> DAO
似乎ruby on rails就是这种模型，他甚至把domain object和DAO都合并了。
该模型优点：
1、简化了分层
2、也算符合OO
该模型缺点：
1、很多不是domain logic的service逻辑也被强行放入domain object ，引起了domain ojbect模型的不稳定
2、domain object暴露给web层过多的信息，可能引起意想不到的副作用。
