XO的解释和作用
之前代码里XO写的不合理被PL吐槽了
POJO(Plain Ordinary Java Object)
首先说一下POJO，简单的 Java 对象。POJO 实质上可以理解为简单的实体类，其中有一些属性及其getter和setter方法的类，没有业务逻辑，也不允许有业务方法，也不能携带有connection之类的方法。
像是PO、VO、DTO都是典型的POJO，是个较为宽泛的概念。
PO(Persistent Object)
PO，持久层对象，它是由一组属性和属性的get和set方法组成，最简单的 PO 就是对应数据库中某个表中的一条记录（也就是说，我们可以将数据库表中的一条记录理解为一个持久层对象），多个记录可以用 PO 的集合，PO 中应该不包含任何对数据库的操作。
PO 的属性是跟数据库表的字段一一对应的，此外 PO 对象需要实现序列化接口。
VO(Value Object/View Object)
Value Object，值对象，是存活在业务层的，是业务逻辑使用的，通常用于业务层之间的数据传递，和 PO 一样也是仅仅包含数据而已，但 VO 应该是抽象出的业务对象，可以和表对应，也可以不对应，根据业务的需要。
VO通常用于业务层之间的数据传递，其仅仅包含数据。但应是抽象出的业务对象。根据业务的需要，其可以和表对应或者不。用new关键字创建，由GC进行回收。
View Object，视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来，对应整个界面的值。
DTO(Data Transfer Object)
DTO，数据传输对象，用于表示一个数据传输对象，通常用于不同服务或服务不同分层之间的数据传输。
比如有一个交易订单表，含有 25 个字段，那么其对应的 PO 就有 25 个属性，但我们的页面上只需要显示 5 个字段，因此没有必要把整个 PO 对象传递给客户端，这时我们只需把仅有 5 个属性的 DTO 把结果传递给客户端即可，而且如果用这个对象来对应界面的显示对象，那此时它的身份就转为 VO。使用 DTO 的好处有两个，一是能避免传递过多的无用数据，提高数据的传输速度；二是能隐藏后端的表结构。常见的用法是：将请求的数据或属性组装成一个 Request DTO，再将响应的数据或属性组装成一个 Response DTO.
DTO概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载
DO(Domain Object)
DO，领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。通常位于业务层中。
BO(Business Object)
BO，业务层对象，是简单的真实世界的软件抽象，通常位于中间层。常常封装了对DAO和RPC等的调用，可以进行PO与VO/DTO之间的转换。
BO 的主要作用是把业务逻辑封装为一个对象，这个对象可以包括一个或多个其它的对象。举一个求职简历的例子，每份简历都包括教育经历、项目经历等，我们可以让教育经历和项目经历分别对应一个 PO，这样在我们建立对应求职简历的 BO 对象处理简历的时候，让每个 BO 都包含这些 PO 即可。
TO(Transfer Object)
TO，数据传输对象。
- 在应用程序不同 tie( 关系 ) 之间传输的对象
- 比如接口间相互的数据传递，使用该对象
- 更多的倾向于，这是一个概念，毕竟接口传输太宽泛，并没有必要按照xxxTO的方式来约束
DAO（Data Access Object）
DAO，数据访问对象。
DAO是SUN公司的一个标准J2EE设计模式，这个模式中有个接口就是 DAO，负责持久层的操作并为业务层提供接口。此对象用于访问数据库。通常和PO结合使用。
DAO中包含了各种数据库的操作方法。通过它的方法结合PO对数据库进行CRUD的操作。
举个栗子
- 用户发出请求（比如填写表单），表单数据在展示层被匹配为
VO - 展示层将
VO转换为服务层对应方法所要求的DTO，传输给服务层，比如POST请求 - 服务层将
DTO的数据构造或重建为一个DO，调用DO的方法完成具体业务 DO完成业务的过程中，可能会有DO到PO的转换，通过DAO方法，完成DO数据的持久化操作
这里缺少了BO和TO两个概念，那么这两个概念在哪儿呢？
我理解为，由于BO并不区分展示层和服务层，所以在展示层，一个页面可以有很多个VO，那么这些个VO就可以组成一个BO，而在服务层，一次业务的处理可以通过一个BO来完成，而这个BO则包含多个PO
TO我们理解为接口间数据传递的对象，比如三层或五层的架构，层与层之间数据交互，就是一个TO，与第三方交互，也是一个TO，TO更多的是一个概念，而非一个规范