废话不多说，先来看这图，看完图估计大部分人就已经有了一个直观的感受了。
DTO（Data Transfer Object）数据传输对象
这个传输通常指的前后端之间的传输
DTO是一个比较特殊的对象，他有两种存在形式：
在后端，他的存在形式是Java对象，通常在后端不需要关心怎么从json转成java对象的，
这个都是由一些成熟的框架帮你完成，比如Spring框架
在前端，他的存在形式通常是JS里面的对象，可以简单理解为JSON这就是为什么把DTO画成横跨两层的原因
VO（View Object）视觉对象
这里通过对比VO与DTO来了解VO
既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。
用一个例子来说明可能会比较容易理解：例如服务层有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？
对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。
PO（Persistant Object）持久对象
简单说PO就是数据库中的记录，一个PO的数据结构对应着表的结构，表中的一条记录就是一个PO对象，所以PO对象等同于Entity对象。
BO（Business Object）业务对象
通过对比BO、PO、DTO来了解BO
对比BO与DTO
BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，只要自己需要的数据，然后对外提供
在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成对比BO与PO
简单的例子比如说PO是一条交易记录，BO是一个人全部的交易记录集合对象
复杂点儿的例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象
