一、失血模型 

失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类。

简单来说，就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。 
Service(业务逻辑，事务封装) --> DAO ---> domain object

这种模型的优点： 
1、各层单向依赖，结构清楚，易于实现和维护 
2、设计简单易行，底层模型非常稳定 

这种模型的缺点： 
1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO 
2、Service层过于厚重

从优缺点来看，简单稳定易维护是失血模型的最大优点，缺点显得不够面向对象，确实是不够面向对象，但是对于中小型项目，业务逻辑并不是很复杂，更多的需求在于稳定运行于可维护扩展，

显然利稍大玉弊，而且此模型结合ORM实现CodeFirst，可以实现快速开发，节省人力和成本，更是中小行项目所青睐的，那么何乐而不为呢。而且这种模型应该根据项目需要来进行调整和修改

不可生搬硬套。

例如我们搞的商城，为了减轻各环节服务器的压力，降低各业务之前的耦合，提高业务模块的复用性。简单的画了张图，这样实现项目需要和替换原有模块上都能方便的实现。

嗯，这里就不得不加一句，符合需求的设计才是最合理的。

 一、充血模型

 充血模型和贫血结构上差不多,不同的是它把大部分与自己相关领域的行为或者逻辑放到领域对象里面了,而业务层或者Service中只有少量的逻辑,简单日志,权限,事务等,这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
   这种模型的优点： 
1、更加符合OO的原则 
2、Service层很薄，只充当Facade的角色，不和DAO打交道。 
这种模型的缺点： 
1、DAO和domain object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。 
2、如何划分Service层逻辑和domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。 
3、考虑到Service层的事务封装特性，Service层必须对所有的domain object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义一遍所有的domain logic，非常烦琐，而且Service的事务化封装其意义就等于把OO的domain logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在domain层实现的OO在Service层又变成了过程式，对于Web层程序员的角度来看，和贫血模型没有什么区别了。