序
各位，既然点进来了，那么大家都一定是对 DO、BO 、VO、DTO 心中抱有疑问。 这些到底是个什么？怎么用？为什么这样分？ 在这里都将给你答案。
是什么？
首先，他们都是 POJO 也就是我们 JAVA 自定义的类，不同的是层级和属性的差别
DO（Data Object）数据层对象
该对象属性与 数据库表字段一一对应 如 DyinggqDO
BO（Business Object）业务层对象
该对象对应 Service 层，即常用开发中 XxxServerImpl 中使用的对象，它与 DO 会有一定的属性差别，通常我们会给出 DO 到 BO 的转换方法，或者使用 Mapper 工具包。如 DyinggqBO
VO（View Object）显示层对象
该对象通常对应于 Controller 层，即我们要最终返回给前端的 JSON 序列化对象。如 DyinggqVO
DTO（Data Transfer Object）数据传输对象
数据传输对象，这个名词初看有点蒙。这样理解，RPC 接口请求接收的对象，或者提供 RPC 接口传输出去的对象，又或者在我们 JAVA 内部调用外部 API JSON 解析 的对象，我们都可以定义为 DTO。如 DyinggqDTO
为什么？
1.为什么要区分这些？
如我们在项目包结构分层一样，区分 POJO 有助于代码的整洁，各司其职，不易混淆乱用，而且在大型项目及复杂场景确实需要如此区分，即需求所在。
2.为什么要区分 DO 和 BO ？
在比较复杂的业务场景下，我们的 Service 层所要使用的 POJO 是 DO 即单表对应类无法满足的，很多情况下在 Service 层可能 BO 会联合几个表进行聚合定义，其属性是聚合处理出来的，可能会有列表或者计算得出的字段，所有 BO 与 DO 的区分是很有必要的。当然在简单的场景下我们直接使用 DO 也并无任何问题，只在真正需要的时候才进行区分定义才是正确的代码之道。
3.为什么还要有 VO ？
很简单的思考，前端并不需要后台所有的数据，对应在接口中，我们只需要返回给他们需要的字段就可以了，避免垃圾数据的传递以及不必要的数据泄露，我们尽可能少的供给前端，让前端自己在他的一亩三分地玩好就行。
3.为什么还要有 DTO ？
经过上面的解释，这个为什么应该很自然而然了吧，很显然 外部请求回来的对象 我们区分一下 定义为 DTO 。舒服的一批好嘛
最后
最后真正需要才区分使用，懂怎么用，知何时用，希望本文对你有所帮助
我是 dying 搁浅 ，我始终期待与你的相遇。无论你是否期待，潮涨潮落，我仅且就在这里…
