PO（Persistent Object）持久对象
用于表示数据库中的一条记录映射成的Java对象，PO仅仅用于表示数据，没有任何数据操作，通常遵守Java Bean的规范，拥有getter/setter方法。
最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合，PO中不应包含任何对数据库的操作。
BO（Business Object）业务对象
用于表示一个业务对象，BO包括了业务逻辑，常常封装了对DAO、RPC等的调用，可以进行PO与VO、DTO之间的转换，BO通常位于业务层，要区别于直接对外提供服务的服务层：BO提供了基本业务单元的基本业务操作，在设计上属于被服务业务流程调用的对象，一个业务流程可能需要调用多个BO来完成。
主要作用是把业务逻辑封装为一个对象，这个对象可以包括一个或多个其他的对象。
比如一个简历，有教育经历、工作经历、社会关系等等，我们可以把教育经历、工作经历、社会关系分别对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO，这样处理业务逻辑时，就可以针对BO去处理。
VO（ViewObject）视图对象
用于表示一个与前端进行交互的Java对象，把某个指定页面（或组件）的所有数据封装起来，只包含前端需要展示的数据即可，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在VO中体现出来，通常遵守Java Bean的规范，拥有getter/setter方法。
DO（Domain Object）领域对象
从现实世界中抽象出来的有形或无形的业务实体。
DTO（Data Transfer Object）数据传输对象
用于表示一个数据传输对象，DTO通常用于不同服务或服务不同分层之间的数据传输，DTO与VO概念相似，并且通常情况下字段也基本一致，但DTO与VO又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。
数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，泛指用于展示层与服务层之间的数据传输对象。
比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。
DAO（Data Access Object）数据访问对象
用于表示一个数据访问对象，使用DAO访问数据库，包括插入、更新、删除、查询等操作，与PO一起使用，DAO一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。
基本没有互相转化的可能性和必要，主要用来封装对数据库的访问，通过它可以把POJO持久化为PO，用PO组装出来VO、DTO。
POJO（Plain Ordinary Java Object）简单普通的Java对象
一个POJO持久化以后就是PO，直接用它传递，传递过程就是DTO，直接用来对应表示层就是VO。
上面说的PO、VO、DTO都是典型的POJO，而DAO、BO一般都不是POJO，只是提供一些调用方法。
纯的传统意义的 java 对象。就是说在一些 Object/Relation Mapping 工具中，能够做到维护数据库表记录的 persisent object 完全是一个符合 Java Bean 规范的纯 Java 对象，没有增加别的属性和方法。我的理解就是最基本的 Java Bean ，只有属性字段及 setter 和 getter 方法。
实例
假如有一个面试系统，数据库中存储了很多面试题，通过Web和API提供服务，做出如下设计：
数据表：表中的面试题包括编号、题目、选项、答案、创建时间、修改时间。
PO：包括题目、选项、答案、创建时间、修改时间。
VO：包括题目、选项、答案、上一题URL、下一题URL。
DTO：包括编号、题目、选项、答案、上一题编号、下一题编号。
DAO：数据库增删改查方法。
BO：业务基本操作。
