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；