后端再向前端传送数据时，需要什么就get 什么数据，但是vo 层是为了解决数据库与页面展示数据不一样的，所以有vo层的必要吗？
首先需要先详细了解下vo、po、dto三者的主要区别，然后就会知道为什么要这么设计了：
VO是视图层对象，作用是给视图页面的数据封装。
PO呢？是持久层对象，作用就是跟持久层的数据作一一对应的关系，相当于一张表一个类，每张表的字段就是每个PO类的属性；
DTO呢？是数据传输对象，主要用于数据传输，比如我们有一个表，含有十几个字段，那么对应的 PO 就有十几个属性，
但我们只需要5 个字段，因此没有必要把整个 PO 对象传递过去，我们只需把5 个属性的 DTO 把结果传递过去即可；
这三个对象实际应用我举个例子你就很好理解了：
比如一个用户在页面操作数据，发出了一个请求。
刚开始数据在页面上展示时候均为VO；VO 的数据是跟页面一一对应。
VO在传到服务层之前，需要将VO转换成DTO再传给服务层。这里转DTO原因之前说了，比如页面有几十个字段，我只要其中几个。没有必要全部给我，所以是转DTO来传输。
然后根据DOT传过来的数据，我们会构造出一个BO，也就是业务逻辑对象，一般在Business这个包。在BO这一段我们会完成具体的业务逻辑。业务逻辑完成后，数据你需要更新到数据库吧？
所以，此时BO的数据就需要转换成对应的PO，因为一个PO对应一张表，所以需要用PO去完成数据的持久化。
这就是整个前端到数据库的流程，也是为什么要设计vo、dto、po的原因，严格意义规范的代码是这三者缺一不可的，按规范来长久下来就能更深层次的了解到每个分层的内在设计了。
希望可以帮到你，如有帮助，希望采纳，感谢🙏
这你怎么说，几方面吧，要说我随手做的一个小项目测试项目，这就跟有时候经常都不写service层，一个道理
存在即合理，在我看来小项目直接都po就差不多了，业务复杂的话vo还是需要的
有必要的，举个很简单的场景，有些前端需要从后端获取枚举类型的数据，这些数据根本不在数据中，也就是一个enum类，但是enum类格式有问题，是不是需要转一下？转成啥呢，一般就是两个：DTO或VO
有，如果没有，你用什么去接呢？
dto？还是实体？dto增加字段到后面你怎么维护，谁知道这个字段是干什么？
如果放在实体，实体类字段就太多了，跟上面按一个道理。
而且用vo可以在保证传值的时候一个地方变更不用全局修改
这个东西想用就用，它的作用就是让人知道这是给前端返回用的，一般我都是response来命名。VO，DTO，DO 这个东西存在只是来区分这个类是用来干啥的，单一职责在此可以借鉴下，见名知意。
当然有啦。
分层领域模型规约：
DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。
BO（Business Object）：业务对象，可以由 Service 层输出的封装业务逻辑的对象。
Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类 来传输。
VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。