贫血模型跟充血模型-摘录

贫血模型:是指领域对象里只有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里实现的业务逻辑全部重新包装一遍,完全属于重复劳动。

时间: 2024-10-09 23:49:30

贫血模型跟充血模型-摘录的相关文章

失血模型,充血模型

一.失血模型 失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类. 简单来说,就是domain ojbect包含了不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到Service层. Service(业务逻辑,事务封装) --> DAO ---> domain object 这种模型的优点: 1.各层单向依赖,结构清楚,易于实现和维护 2.设计简单易行,底层模型非常稳定 这种模型的缺点: 1.domain object的部分比较紧密依赖

贫血模型和充血模型

贫血模型:领域对象里只有get和set方法,或者包含少量的CRUD方法,而不包含有业务逻辑的处理,把"行为"和"状态"分离到不同的对象里,只有状态的对象被称为"贫血对象"(VO),而只有"行为"的对象一般被用作服务对象,就像spring的server一样,都是无状态对象,本身并不存储数据,只处理逻辑. 充血模型:业务逻辑和持久化都放在对象中,Business Logic(业务逻辑层)只负责简单封装部分业务逻辑以及控制事务.权限

领域模型、贫血模型、充血模型概念总结

领域模型 领域模型是对领域内的概念类或现实世界中对象的可视化表示.又称概念模型.领域对象模型.分析对象模型.它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系. 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型.它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象.业务对象模型从业务角色内部的观点定义了业务用例.该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系.它

领域模型(domain model)&贫血模型(anaemic domain model)&充血模型(rich domain model)

领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系. 贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层.有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象有少量的业务逻辑),就不对此加以区分了. 充血模型将大多数业务逻辑和持久化放在领域对象中,业务逻辑(业务门面)

贫血,充血模型的解释以及一些经验

为了补大家的遗憾,在此总结下ROBBIN的领域模型的一些观点和大家的补充,在网站和演讲中,robbin将领域模型初步分为4大类: 1,失血模型 2,贫血模型 3,充血模型 4,胀血模型 那么让我们看看究竟有这些领域模型的具体内容,以及他们的优缺点: 一.失血模型 失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类,所有的业务逻辑完全由business object来完成(又称Transaction Script),这种模型下的domain obje

什么是领域模型(domain model)?贫血模型(anaemic domain model) 和充血模型(rich domain model)有什么区别

http://blog.csdn.net/helloboat/article/details/51208128 领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系.贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层.有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象

从经典架构项目中透析微服务架构的核心概念和充血模型

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制:需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑:同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息:都需要统一的Gateway来汇

多研究些架构,少谈些框架(2)-- 微服务和充血模型(转)

上篇我们聊了微服务的DDD之间的关系,很多人还是觉得很虚幻,DDD那么复杂的理论,聚合根.值对象.事件溯源,到底我们该怎么入手呢? 实际上DDD和面向对象设计.设计模式等等理论有千丝万缕的联系,如果不熟悉OOA.OOD,DDD也是使用不好的.不过学习这些OO理论的时候,大家往往感觉到无用武之地,因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的(Action.Service.Dao),在这种分层理论中,我们基本没有啥机会使用那些所谓的"行为型"的设计模式,这里的核心

极客设计模式之美学习-传统MVC和DDD充血模型(二)

贫血模型 贫血模型例子 现在传统的MVC开发基本上都是贫血模型 如以下代码 我们工作中经常使用 ////////// Controller+VO(View Object) ////////// public class UserController { private UserService userService; //通过构造函数或者IOC框架注入 public UserVo getUserById(Long userId) { UserBo userBo = userService.get