世上本没有路，走的人多了就有了，走的人更多一点，路的就多了，连种类也多了。乡间小道、柏油马路、高速路、铁路……
JAVA是面向对象编程，原本一个对象就解决了所有问题，但是用的地方多了一个对象就不够用了，就有了衍生版本。PO、VO、DO……应运而生，但是没看到一个官方的权威性的定义，各个版本也有不同的说法，这里谈谈我的个人理解。我们先来看看他们的定义：
- VO（View Object）： 视图对象，用于展示层，主要用于页面展示以及将页面的数据传送给控制器。
- DO（Domain Object/Data Object）： 一种说法是Domain Object，领域对象，是对现实生活中的抽象对象，另一种说法是Data Object，也就是数据对象，他的内容和数据库表结构一致，个人比较赞成这种说法。
- DTO（Data Transfer Object）： 数据传输对象，主要用于Service和Manager层向外传输的对象。
- PO（Persistent Object）： 持久化对象，它和数据库表结构一致。
- BO（Business Object）： 业务对象，可以由Service层输出的封装业务逻辑的对象。
- POJO（Plain Ordinary Java Object）： 一般Java对象，DO、VO、DTO等的统称
- Query： 数据查找对象，各层接收上层的查询对象。
- Entity： 实体类，基本和数据库表结构一致
- Domain： 与POJO一样，一种对象的统称
这么多对象，我们该怎么用呢？是不是所有对象都要用上呢？
编码风格也是分派系的，不同派系有自己的特点，也不需要用到所有的对象。业界比较良心的阿里派系，《阿里巴巴 Java 开发手册》中就只有DO、DTO、BO、VO和Query五种对象。如果你够豪横，就用一个对象处理所有问题也是完全可以的，但是这样做，代码的可维护性就太差了，而且可能会造成数据安全问题和性能问题。例如我们有对象Book和User两个对象
/**
* @Description 书籍
* @Author Rogear
* @Date 2020/9/11 10:58
*/public class Book {
/**
* 自增id
*/ private Long id;
/**
* 书籍名称
*/ private String name;
/**
* 售价
*/ private Double price;
/**
* 作者
*/ private String Author;
/**
* 发布时间
*/ private Date publishTime;
...(省略get和set方法)
}
/**
* @Description 用户
* @Author Rogear
* @Date 2020/9/11 11:01
*/public class User {
/**
* 自增id
*/ private Long id;
/**
* 用户姓名
*/ private String name;
/**
* 密码
*/ private String password;
/**
* 性别
*/ private String gender;
/**
* 书籍
*/ private List<Book> bookList;
...(省略get和set方法)
}
如果界面上需要展示用户信息，那我们需要处理敏感信息，例如将密码隐藏起来或者直接不传给视图层。如果我们新建一个UserVO，里面直接不包含敏感信息，那是不是更方便呢？
再则，如果我们要对用户信息做CRUD操作的时候，传输过程中带有了非用户基本信息，例如上面的bookList。一方面这个数据对当前业务没有用，无意义，另一方面这样会让对象变大，字节更多，网络传输的时候会更加慢影响系统性能。如果我们在各业务里面造一个只包含用户基本信息的对象，那就比较完美了。
由于种种原因的驱使，我们需要使用不同对象，那什么情况下用什么对象呢？
首先抽象概念的对象，POJO、Domain、Entity三个对象概念过于抽象笼统，见名不知意，建议代码中就不要使用了，我们应该用一些更加具体化的对象。
VO直接和视图层进行交互，无论是控制器向界面展示数据，还是界面提交表单等都用VO。
DO/PO直接和数据库进行交互，写数据库和读数据库都用他。
DTO用于数据传输，可以用在Service层和Manager层。
Query用于查询对象封装，比如我们要去查询莎士比亚写的《哈姆雷特》，我们可以造一个BookQuery去传参数
对象的一般应用领域如下图，但是也不是绝对的。例如界面上需要展示User信息，也要展示User的BookList信息，我们也可以直接用VO对象去数据库查数据，然后直接返回到界面上。
