一、概念

在Java编程中，VO、DTO、DO、BO这四个术语都代表了不同的对象类型，它们之间的区别与联系如下：

1、VO (View Object)

VO (View Object)，用于表示一个与前端进行交互的视图对象，它的作用是把某个指定页面(或组件)的所有数据封装起来。实际上，这里的VO只包含前端需要展示的数据，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在VO 中体现出来。

2、DTO(Data Transfer Object)

DTO(Data Transfer Object)，用于表示一个数据传输对象，DTO通常用于展示层(Controller)和服务层(Service)之间的数据传输对象。DTO 与 VO概念相似，并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO就可能与 VO 存在差异。

3、DO(Data Object)

DO(Data Object)，持久化对象，它跟持久层(Dao)的数据结构形成一一对应的映射关系。如果持久层是关系型数据库，那么数据库表中的每个字段就对应PO的一个属性，常是entity实体类。

4、BO（Business Object）

BO（Business Object）：业务对象，通常用于业务逻辑层，代表了业务逻辑的实现。BO主要负责业务逻辑的处理，包括数据校验、数据处理、业务逻辑处理等。BO可以调用多个DO，将多个DO组合起来，形成一个完整的业务流程。

二、为什么会存在Vo？

项目中，看到别人直接把DTO，写上swagger注释，直接返回前端。那么思考一下，为什么不建议这么做，不直接把DTO返回给前端。

⭕ 从开发过程讲，前后端首先会以vo和param作为返回、传参的协议的定义，再定义协议之前，都没有实际的业务逻辑的处理，也就不会存在dto。

⭕从项目的整体考虑，如果把dto作为传给前端的对象，那么service层返回dto，service层的所有的方法不一定都是public方法，也有private方法，如果private方法也返回dto，那么也就是说有些dto不是提供给前端的，有些是给前端的，这样就会乱，没有了隔离性。

⭕从字段的修改来说，service层的方法是可以共用的，一个service方法返回的dto，可能会被很多个controlller方法使用到，即使目前不会，将来也可能会，dto会有很多参数，比如包含了主表信息，子表信息，而传给前端的vo只有dto的一部分信息，而且不同请求给前端看到的数据不一样，所以dto是共用的，vo是个性化的，如果直接把dto提供给前端，将会导致耦合性非常大，一旦一个接口的需求变了，修改了dto，增加了一个字段，将会导致接口直接把这个新增的字段返回给了前端，导致（接口输出数据多余，和不安全性）。同理，如果由于某个需求，把dto展示给前端的接口说要删除某一个字段，那么因为这个dto被很多接口引用，一删除就会导致出问题。

所以，总整体性结构而言：vo是必须存在的，不能把dto直接返回给前端。高内聚，低耦合。一般的数据传递是，前端传递VO给接口(Controller)，接口将VO转为DTO传递给service，service将DTO分解为DO，调用领域服务进行调度，然后逆向转为VO或者其他的返回结果，传递给前台。

三、总结

总的来说，VO、DTO、DO、BO是分层架构中的不同对象，每个对象在各自的层次中承担着不同的角色，各自有自己的特点和用途。在实际开发中，要根据业务需求和架构要求，灵活使用这些对象，使得系统的耦合性和复杂度得到合理的控制和降低。