总图：
1、DTO介绍
DTO（Data Transfer Object）数据传输对象
这个传输通常指的前后端之间的传输
DTO是一个比较特殊的对象，他有两种存在形式：
在后端，他的存在形式是java对象，也就是在controller里面定义的那个东东，通常在后端不需要关心怎么从json转成java对象的，这个都是由一些成熟的框架帮你完成啦，比如spring框架
在前端，他的存在形式通常是js里面的对象（也可以简单理解成json），也就是通过ajax请求的那个数据体
这也是为什么把他画成横跨两层的原因
这里可能会遇到个问题，现在微服务盛行，服务和服务之间调用的传输对象能叫DTO吗？
我的理解是看情况
DTO本身的一个隐含的意义是要能够完整的表达一个业务模块的输出
如果服务和服务之间相对独立，那就可以叫DTO
如果服务和服务之间不独立，每个都不是一个完整的业务模块，拆开可能仅仅是因为计算复杂度或者性能的问题，那这就不能够叫做DTO，只能是BO
DTO（Data Transfer Object）数据传输对象，主要用于远程调用等需要大量传输对象的地方，比如我们有一个交易订单表，含有 25 个字段，那么其对应的 PO 就有 25 个属性，但我们的页面上只需要显示 5 个字段，因此没有必要把整个 PO 对象传递给客户端，这时我们只需把仅有 5 个属性的 DTO 把结果传递给客户端即可。
还有一种就是前段传过来的数据中没有实体类能接受，比如出传递回来10个参数，其中9个参数是可以让一个现有的实体类来接受的，但是另外一个参数是没有的，所以创建一个DTO类来进行对数据的接收。使用 DTO 的好处有两个：
一是能避免传递过多的无用数据，提高数据的传输速度；
二是能隐藏后端的表结构。
常见的用法是：将请求的数据或属性组装成一个 RequestDTO，再将响应的数据或属性组装成一个 ResponseDTO.
2、DTO使用
（1）页面传给后端的数据
其中里面的参数除了dish菜品表的属性之外，还有一个flavors属性，但是dish中没有
所以我们创建DTO类。
（2）DTO类
其中List属性用来接收前端传来flavors属性（因为前端传来的flavors数据中可能会有多个，所以用一个List集合来接收）
DishFlavor类中有对应name和value属性字段来接收flavors属性。注意DishDto继承Dish
所以有Dish的属性
注意：上面Dto继承了Dish类，所以可以接收前端传来Dish相关的属性！！！！
service中的方法：
上面代码中，首先先将dishDto中有关菜品的基本信息保存到菜品表中。然后得到dishId，然后通过stream流（也可以使用foreach循环）遍历item，这里的item对象是dishflavors类的，不仅要存储前端传来的flavors属性数值，我们将dishId数值传到item对象的属性，菜品口味表中不能只有口味相关信息，还要包含菜品的ID。
最后将对象转成list集合，然后赋值给flavors集合类。然后作为参数保存到菜品表中。
//注意上面只有Flavors的数据，没有dishId数据，而dish_flavors数据库表中有，所以我们需要将该dishId数据
//赋值给该集合的每一个元素（对象）的dishId属性，然后在转化为集合保存到flavors表中
3、VO
VO（Value Object）值对象
VO就是展示用的数据，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，这就叫VO
VO主要的存在形式就是js里面的对象（也可以简单理解成json）
4、PO
PO（Persistant Object）持久对象
PO比较好理解
简单说PO就是数据库中的记录，一个PO的数据结构对应着库中表的结构，表中的一条记录就是一个PO对象
通常PO里面除了get，set之外没有别的方法
对于PO来说，数量是相对固定的，一定不会超过数据库表的数量
5、BO
BO（Business Object）业务对象
BO就是PO的组合
简单的例子比如说PO是一条交易记录，BO是一个人全部的交易记录集合对象
复杂点儿的例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象
BO是一个业务对象，一类业务就会对应一个BO，数量上没有限制，而且BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法
为什么BO也画成横跨两层呢？原因是现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成
很多情况下为了追求查询的效率，框架跳过PO直接生成BO的情况非常普遍，PO只是用来增删改使用
BO和DTO的区别
这两个的区别主要是就是字段的删减
BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，只要自己需要的数据，然后对外提供
在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成
OK，到这里这些关系基本就理清楚了
6、总结
dto（请求参数可能会与vo不同，sql传参使用）, po（持久层查询结果，返回使用po接收）, vo（页面展示，po转换成vo反给前端）, 对非微服务系统来说，业务层service相当于bo了