VO:Value Object,值对象。
- 通常用于业务层之间的数据传递,由new创建,由GC回收;例如:将商品信息和用户信息重新用一个对象封装起来。
- 和PO一样也是仅仅包含数据而已,但应是抽象出的业务对象,可以和表对应,也可以不是。
- 另外一种说法:VO(View Object):VO是显示视图模型,视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。举例:展示层将DTO传送过来男性显示成帅哥(客户端1),或者显示成靓仔(客户端2);将帅哥或者靓仔,转换成男性,以DTO形式请求服务端。
PO:Persistant Object,持久层对象。(可以认为就是Entity)
- PO是 ORM 框架中Entity,PO属性和数据库中表的字段一一对应。
- VO和PO,都是属性加上属性的get和set方法;表面看没什么不同,但代表的含义是完全不同的。基本上持久对象生命周期和数据库密切相关。
Entity:实体类对象。
- 实体,和PO的功能类似,和数据表一一对应,一个实体一张表。
- 注:关于区分POJO和entity,查了一些资料也没发现有特别大的差别,功能上来说差别不大,只能从含义上大致区分一下。不过现在大都是用entity来作为一个表映射的类。
DTO:Data Transfer Object,数据传输对象。
- **在这里泛指用于展示层与服务层之间的数据传输对象。**那么问题来了,为什么要用DTO呢? 为什么不能直接用实体模型呢?
- 举个例子:
- 比如我们一张表有100个字段,那么对应的PO就有100个属性。
- 但是我们界面上只要显示10个字段。
- 客户端用service来获取数据,没有必要把整个PO对象传递到客户端。
- 这时我们就可以用只有这10个属性的DTO来传递结果到客户端,这样也不会暴露服务端表结构。
- 简单来说:就是当数据库表中的字段太多了,只提取出数据表中的某些字段,将其封装为一个DTO对象传给客户端。
- DTO由此产生,一是能提高数据传输的速度(减少了传输字段),二能隐藏后端表结构。
DO:Domain Object,领域对象,作用于业务层与dao层之间。
- service使用接收到的DTO数据传输对象构造或者重构DO对象,传递到dao层。
BO:Business Object,业务对象。(不常用)
- BO是封装业务逻辑的Java对象,通过调用DAO方法,结合PO,VO进行业务操作。
- 举个例子:
- 比如一个简历,有教育经历、工作经历、社会关系等。
- 我们可以把教育经历对应一个PO,工作经历对应一个PO,社会关系对应一个PO。
- 建立一个对应简历的BO对象处理简历,每个BO包含这些PO。
- 这样处理业务逻辑时,我们就可以针对BO去处理。
POJO:Plain Ordinary Java Object,简单无规则java对象。
- 一般只有属性字段,无参构造以及get和set方法,也是指那些没有从任何类继承、也没有实现任何接口,更没有被其它框架侵入的Java对象。因此它特别灵活可扩展,可以实现让一个模型贯穿多个层,简单来说可以理解成不包含业务逻辑的单纯用来存储数据的Java类。
- 可以转化为PO、DTO、VO。
- 一个POJO持久化以后就是PO;
- 直接用它传递、传递过程中就是DTO;
- 直接用来对应表示层就是VO;