充血模式和贫血模式
来源:互联网 发布:床聊软件骗局 编辑:程序博客网 时间:2024/04/26 06:42
贫血模型:是指领域对象里只有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的透明持久化支持,那么充血模型还是能够实现的。
选择了.NET平台开发,就是选择了开发高效、功能强大应用简单,最适合的模型就是贫血模型,或表数据入口,既有编译器和语言平台很好的支持,也符合微软提倡的开发模式。如果跟潮流在项目中使用充血模型,现有的ORM工具都很复杂难用,光是维护大量的映射文件都成问题。说贫血不够OO,它的Domain Object不够丰富,能把项目做好了,有一定的扩展能力和伸缩行就行了,也不一定要讲究优雅的面向对象。正如SOA,讲究松耦合、高内聚,服务端给客户端提供的服务,也就是一系列的方法调用加上DTO而已,不管服务的内部是不是面向对象的实现,至少它暴露出来的是过程式的服务。
优点是系统的层次结构清楚,各层之间单向依赖,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的透明持久化支持,那么充血模型还是能够实现的。
选择了.NET平台开发,就是选择了开发高效、功能强大应用简单,最适合的模型就是贫血模型,或表数据入口,既有编译器和语言平台很好的支持,也符合微软提倡的开发模式。如果跟潮流在项目中使用充血模型,现有的ORM工具都很复杂难用,光是维护大量的映射文件都成问题。说贫血不够OO,它的Domain Object不够丰富,能把项目做好了,有一定的扩展能力和伸缩行就行了,也不一定要讲究优雅的面向对象。正如SOA,讲究松耦合、高内聚,服务端给客户端提供的服务,也就是一系列的方法调用加上DTO而已,不管服务的内部是不是面向对象的实现,至少它暴露出来的是过程式的服务。
0 0
- 充血模式和贫血模式
- 充血模式和贫血模式
- 传统三层结构和MVC之于贫血模式和充血模式以及领域建模
- 贫血模型和充血模型
- 贫血模型和充血模型
- 贫血模型和充血模型
- 贫血对象和充血对象
- 贫血模型和充血模型
- 贫血模型和充血模型
- 充血模型和贫血模型
- 贫血模型和充血模型
- 说说领域驱动设计和贫血、失血、充血模型
- 说说领域驱动设计和贫血、失血、充血模型
- 浅析:领域模型、贫血模型和充血模型
- 贫血模式or领域模式
- 贫血模型与充血模型
- 微服务下DDD的充血模式
- 从贫血到充血Domain Model
- [linux device driver] Chapter 03:以scull_load为引,详解shell逻辑运算、基本运算、位运算
- [学海拾贝]状态机思路在单片机程序设计中的应用
- python lxml xpath 使用实例!
- sqlite3使用简介
- 使用u-boot烧写linux
- 充血模式和贫血模式
- 品牌H5营销完全实战指南
- 关于屏幕适配问题的工作<个人记录>
- 使用jaxp进行sax解析
- final与类变量初始化问题
- EBS报表查看输出的时候,设置成提示下载xls文件的方法
- 关于iOS编译指令集
- 从Storm和Spark 学习流式实时分布式计算的设计
- Tomcat:基于Apache+Tomcat的集群搭建