| VO | view object：视图对象，用于展示层，把某个指定页面的展示数据封装起来 |
|---|---|
| DTO | Data Transfer Object：用于展示层与服务层之间的数据传输对象 |
| BO | Business Object：业务对象，把业务逻辑封装成一个对象 |
| PO | Persistent Object：持久层对象，和持久层（如数据库）形成对应的映射关系 |
| DO | Domain Object：领域对象，从现实世界中抽象出的有形或无形的业务实体 |
易混点一：VO和DTO
首先VO是最常用的，view object，一般说视图对象。说白了它就是展示用的，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，我们就把它封装为VO。
VO比较容易混淆的是DTO，DTO是展示层与服务层之间传递数据的对象，可以这样说，对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，那么既然有了VO，为什么还需要DTO呢？
我们举例来说明一下：
某公司有一个后台服务，服务层有一个getUser的方法返回一个系统用户，包含sex(性别)、年龄。对于服务层来说，DTO只从语义上定义，可能是这样的：
{
"gender":"男",
"age":35
}
但这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，比如管理端要求显示准确的年龄，而应用端为了保护客户隐私，只需要显示一个年龄段即可。
管理端VO：
{
"gender":"男",
"age":35
}
应用端VO：
{
"gender":"男",
"age":30~40
}
从这个例子可以看出，DTO很有存在的必要，根据职责单一原则，服务层只负责业务，与具体的表现形式无关，DTO不应该出现与表现形式的耦合，DTO定义的是原始数据，VO再对DTO数据进行解释。这下VO和DTO用法就清晰很多了。
易混点二：BO和PO
PO是持久对象，就是实体和数据库字段的对应，一个PO的数据结构对应着库中表的结构，大多数情况下，PO仅仅作为PO只是用来增删改使用。
PO比较容易混淆的是BO，BO是业务对象，对应的是某个具体的业务块，可以包含多个属性、对象。简单点来说，我们可以把BO看作是PO的组合。
我们举例来说明一下：
PO-1是交易记录对象，PO-2是登录记录对象，PO-3是商品浏览记录对象，PO-4是添加购物车记录对象，PO-5是搜索记录对象，BO是个人网站行为对象，BO对象：{PO-1;PO-2;PO-3;PO-4;PO-5}。这样做的优点不言而喻，维护代码的时候查看BO，就能知道这块逻辑涉及多少表（PO）。
易混点三：BO和DTO
搞清楚了BO和PO各自的用途后，我们会发现BO和DTO有重叠功能，一样可以对PO进行排列组合，那BO的存在的意义是什么呢？
从用途上进行根本的区别，BO是业务对象，DTO是数据传输对象，虽然BO也可以排列组合数据，但它的功能是对内的，比如上个例子中的BO对象包括{PO-1;PO-2;PO-3;PO-4;PO-5}还有其他字段属性，但在提供对外接口时，BO对象中的某些属性对象可能用不到或者不方便对外暴露，那么此时DTO只需要在BO的基础上，抽取自己需要的数据，然后对外提供。
在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成。
DO
DO是领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。事实上，DO和PO在绝大部分情况下是一一对应的。
总结
- PO与DO一般是相等的
- DTO用户展示层向业务层传递数据（数据属性越少越好）
- VO用户展示层返回数据给视图层
- BO一般是一个业务逻辑需要用到的类（PO的组合）
另附这些概念命名规范：
数据对象：xxxPO，xxx即为数据表名。(也可DO)
数据传输对象：xxxDTO，xxx为业务领域相关的名称。
展示对象：xxxVO，xxx一般为网页名称。
业务对象：xxxBO，xxx是业务名称。
