前言

本博主将用CSDN记录软件开发求学之路上亲身所得与所学的心得与知识,有兴趣的小伙伴可以关注博主!也许一个人独行,可以走的很快,但是一群人结伴而行,才能走的更远!

一、概念

在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)之间的数据传输对象。DTOVO概念相似,并且通常情况下字段也基本一致。但 DTOVO 又有一些不同,这个不同主要是设计理念上的,比如 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返回给前端。

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

从项目的整体考虑,如果把dto作为传给前端的对象,那么service层返回dtoservice层的所有的方法不一定都是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是分层架构中的不同对象,每个对象在各自的层次中承担着不同的角色,各自有自己的特点和用途。在实际开发中,要根据业务需求和架构要求,灵活使用这些对象,使得系统的耦合性和复杂度得到合理的控制和降低。

Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐