Android充血模型以及贫血模型

贫血模型

        贫血模型：是指领域对象里只有get和set方法，或者包含少许的CRUD方法，全部的业务逻辑都不包含在内而是放在Business Logic层。

        优势是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。固然Business Logic是依赖Domain Object的。彷佛如今流行的架构就是这样，固然层次还能够细分。
        该模型的缺点是不够面向对象，领域对象只是做为保存状态或者传递状态使用，因此就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处理全部的业务逻辑，在POEAA(企业应用架构模式)一书中被称为Transaction Script模式。

充血模型

        充血模型： 层次结构和上面的差很少，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。

        优势是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含全部的业务逻辑太过沉重。
        缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即便划分好了业务逻辑，因为分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员须要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来讲这十分混乱。 其次，由于Business Logic要控制事务而且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑所有从新包装一遍，彻底属于重复劳动。

        若是技术可以支持充血模型，那固然是最完美的解决方案。不过如今 的.NET框架并无ORM工具（不算上开源的NHibernate，Castle之类），没有ORM就没有透明的持久化支持，在Domain Object层会对Data Access层构成依赖，若是脱离了Data Access层，Domain Object的业务逻辑就没法进行单元测试，这也是很致命的。若是有像Spring的动态注入和Hibernate的透明持久化支持，那么充血模型仍是能 够实现的。

 

 

 

        使用RoR开发时， 每个领域模型对象均可以具有本身的基础业务方法，一般知足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。

 

充血模型的层次和模块的划分是一门学问，对开发人员要求亦较高，能够考虑定义这样的一些规则：

（1）事务控制不要放在领域模型的对象中实现，能够放在facade中完成。

（2）领域模型对象中只保留该模型驱动的通常方法，对于业务特征明显的特异场景方法调用放在facade中完成。