区别简述
(Data Object)，数据库表的对应实体类，DO的属性与表的字段一一对应。
(Persistant Object)，持久层对象，跟DO是一个意思。
(Bussiness Object)，业务对象，用于业务逻辑层（即serviceImpl层）之间传输数据。
(Data Transfer Object)，数据传输对象，用于封装展示层的请求参数和响应结果，以及服务层（即service层）和展示层（controller层）之间传输数据。
(View Object)，用于展示层封装请求响应结果，与DTO概念相似，后面会讲两者区别。
下面以一个简单的需求为例，展示这几者的区别
需求：有学生和班级两个对象，需要通过年龄区间筛选学生，查询结果包括学生姓名、年龄以及对应的班级名称
demo如下（为了明显的展示这几者区别，demo尽可能的简略）
首先，是定义学生和班级的DO
public class StudentDO {
/**
* id
*/
private Integer id;
/**
* 学生姓名
*/
private String studentName;
/**
* 年龄
*/
private Integer age;
}
public class ClassDO {
/**
* id
*/
private Integer id;
/**
* 班级名称
*/
private String className;
}
接下来是controller层封装请求参数
显然，StudentDO和ClassDO都不满足我们筛选条件的要求，两者都没有年龄区间的属性。
因此需要定义一个DTO来封装请求参数
public class StudentRequestDTO {
/**
* 年龄区间开始
*/
private String ageBegin;
/**
* 年龄区间结束
*/
private String ageEnd;
}
现在，StudentRequestDTO来到了service层，需要根据参数找到最后展示到界面上的信息。
假设根据学生年龄找到学生信息以及对应的班级信息，需要复杂的业务逻辑，需要在serviceImpl层之间传输各种数据，那么就需要BO来封装业务逻辑层需要的数据
（注：BO可能有多个）
public class StudentClassBO {
// 假设这里有很多很多属性
...
}
经过错综复杂，扑朔迷离的逻辑计算，service层终于找全了信息，我们用StudentClassDTO来封装。
public class StudentClassDTO {
/**
* 学生姓名
*/
private String studentName;
/**
* 年龄
*/
private Integer age;
/**
* 班级名称
*/
private String className;
}
历尽千辛万苦，service层终于把StudentClassDTO带到了controller层，需要封装请求的响应结果，包括学生姓名、年龄和班级名称。
此时我们发现，StudentClassDTO已经满足了要求，所以可以直接把StudentClassDTO返回。
但是！！！
假如存在不同客户端，且不同客户端的展示要求不同，比如老年机需要正常显示数字的年龄，少年机需要把年龄转化为妹妹哥哥叔叔阿姨等称呼，那么StudentClassDTO类Integer类型的age属性，就无法满足要求。
这时，就需要再定义一个StudentClassVO，来满足这个功能。
当然你可以给StudentClassDTO加属性来完成功能，但是万一以后有更复杂（nao can）的需求呢？
---------------------------------分割线---------------------------------
现在，我们改变一下筛选条件和响应结果：
根据姓名，筛选学生
响应结果包括年龄和姓名
此时，筛选条件和响应结果都在StudentDO中，不需要BO、DTO、VO也能满足需求。
假如你在项目中到处使用StudentDO。然后！！！一个月黑风高的夜晚，产品突然说筛选条件或响应结果需要增加其他信息，StudentDO无法满足要求，这时候你再改代码，改动量就会很大，同样的风险也很大。
如果你一开始就区分开DTO、BO，不然需求怎么变化，只需要在DTO和BO增加属性，代码改动量就小了很多。
1.设计DO/DTO/BO/VO，不仅是为了满足当前需求，更是为了满足以后需求的变化；
2.如果StudentDO与数据库表没有保持一一对应，使用ORM框架时可能会有问题，所以需要其他类来封装其他信息；
3.不同公司对类的命名规范不尽相同，有的公司用xxxRequestDTO、xxxResponseDTO分别表示筛选条件和响应结果；有的公司xxxEntity表示数据库表的对应实体类，不叫DO/PO。同一个业务对象，可能有多个DTO，命名时要加以区分，如StudentQueryDTO, StudentAddDTO等，不要直接命名为StudentDTO；
4.同一个公司/项目，最好遵循同一个命名规范，最好在脚手架就定义好do、dto、bo、vo等包名；
5.VO不是必选项，大多数情况下，使用DTO即可完成任务，但有的公司命名规范就是用VO，而且用VO更能体现出展示层与服务层的不同。
