POJO
简单的JAVA对象(PlAIn ordinary Java Objects)实际就是普通JavaBeans,使用POJO名称是为了避免和EJB混淆起来, 而且简称比较直接。
其中有一些属性及其getter setter方法的类,有时可以作为value object或dto(Data Transform Object)来使用。
当然,如果你有一个简单的运算属性也是可以的,但不允许有业务方法,也不能携带有connection之类的方法。
PO
PO(persistant object) 持久对象,可以看成是与数据库中的表相映射的java对象。一张表对映一个PO。
最简单的PO就是对应数据库中某个表中的一条记录,多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。
DAO
DAO (data access object) 数据访问对象,此对象用于访问数据库。
通常和PO结合使用,DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作。
DTO
DTO (Data Transfer Object)
数据传输对象,主要用于远程调用等需要大量传输对象的地方。比如我们一张表有100个字段,那么对应的PO就有100个属性,但是我们界面上只要显示10个字段,客户端用WEB service来获取数据,没有必要把整个PO对象传递到客户端,这时我们就可以用只有这10个属性的DTO来传递结果到客户端,这样也不会暴露服务端表结构。到达客户端以后,如果用这个对象来对应界面显示,那此时它的身份就转为VO。
VO
VO(value object) 值对象,通常用于业务层之间的数据传递,和PO一样也是仅仅包含数据而已。
但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要。个人觉得同DTO(数据传输对象),在web上传递。
BO
BO:全称是business object:业务对象,主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
比如一个简历,有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个PO,工作经历对应一个PO,社会关系对应一个PO。
建立一个对应简历的BO对象处理简历,每个BO包含这些PO。这样处理业务逻辑时,我们就可以针对BO去处理。
biz
biz是Business的缩写,是业务逻辑层,一般意义上和service层差不多。项目前期或者小项目没什么太大区别,但是项目大了以后区别就很大了。
项目开发到后期的话,一个项目内包含有其他的小项目,比如:后台、erp、商城等等,都用的是同一个数据库。这个时候,就不能使用一个service/biz 全部解决了。有些业务是通用的,有一些业务可能只有erp有,其他模块没有,也有可能同一个业务,在细微上有一些差别,如果全部都放进一个业务层中的话,这个业务层就会非常的臃肿。这个时候就需要拆分,一个基础业务层,一个应用层业务层,基础业务层只是针对该对象的CURD操作
应用业务层就是一个复杂的功能模块或流程。
这时可以考虑service作基础业务层,biz作为应用层业务层。service是比较底层的api,biz是应用层的api。可以结合DDD领域驱动设计理解。
充血模型与贫血模型
贫血模型最早广泛应用是源自于EJB2,最强盛时期则是由Spring创造,把“行为”(也称为逻辑、过程)和“状态”(可理解为数据,对应到语言就是对象成员变量)分离到不同的对象之中,那个只有状态的对象就是所谓的“贫血对象”(常称为VO——Value Object),而那个只有行为的对象就是我们常见的N层结构中的Logic/Service/Manager层(对应到EJB2中的Stateless Session Bean)。
充血模型其实很简单,就是面向对象设计的本质:“一个对象是拥有状态和行为的”,比如说一个人,他眼睛什么样鼻子什么样这就是状态,人可以去打游戏或是写程序,这就是行为。
总结
贫血模型, 将数据与db操作分离, 分个好几层, 如entity/dao/service等。
充血模型, 数据与db操作绑在一次, 一般只涉及到一两层。
充血模型层数少,代码少, 改动少, 简单, 优雅,一般复杂的系统可以考虑用充血模型,简单系统用贫血模型也并没有什么影响。
如若转载,请注明出处:开源字节 https://sourcebyte.cn/article/229.html