robbin四大模型

模型包括：

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层过多的信息，可能引起意想不到的副作用。