VO、DTO、DO、BO的区别与联系
- 前言
- 一、概念
- 1、VO (View Object)
- 2、DTO(Data Transfer Object)
- 3、DO(Data Object)
- 4、BO(Business Object)
- 二、为什么会存在Vo?
- 三、总结
前言
本博主将用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
)之间的数据传输对象。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是分层架构中的不同对象,每个对象在各自的层次中承担着不同的角色,各自有自己的特点和用途。在实际开发中,要根据业务需求和架构要求,灵活使用这些对象,使得系统的耦合性和复杂度得到合理的控制和降低。