VO、BO、DO 详解

VO(View Object)、BO(Business Object)等是Spring开发中常用的概念:

• VO:也称为DTO(Data Transfer Object),主要用于展示层,用于封装要传输给前端或移动端的数据。通常VO中只包含数据,不包含业务逻辑。

• BO:主要用于业务层,用于封装业务逻辑。BO可以通过组合其他BO或者直接使用实体类来实现业务。

• DAO:主要用于数据访问层,用于调用数据库查询、更新数据等操作。通常通过repository或mapper实现数据查询和持久化。

• DO/POJO(Plain Ordinary Java Object):主要用于映射数据库表结构到Java对象,通过ORM框架映射到实体类。也可以直接作为BO使用。

使用场景:

• Controller层可以接收DO/DTO/VO作为输入,返回DO/DTO/VO给调用方。

• Service层接受DO/DTO/VO输入,组合和使用BO执行业务逻辑,返回DO/DTO/VO。

• DAO层使用DO与数据库交互,实现对数据库的操作。

所以一般来说,Controller与前端交互使用VO;Service层使用BO封装业务,输入输出常用DTO或DO;DAO层使用DO与数据库交互。这种层次划分可以使职责清晰,也方便维护和扩展。

对于SpringBoot中的VO、BO、DO等的详细区别和使用场景的解释如下:

DO(Data Object)、POJO(Plain Ordinary Java Object)

这主要指与数据库映射的实体类,直接反应了数据库表的结构,每个实体类通常对应一个数据库表。主要包含实体的属性、getter/setter方法、序列化方法等。

Pros:

• 与表结构映射,使数据持久化更方便
• 不同业务可重用相同DO

Cons:

• 多表关联查询较复杂
• 和数据库耦合度高

DTO(Data Transfer Object)、 VO(View Object)

这些类主要用于展示层，用于向客户端传输数据。通常和请求参数、返回值对应，只包含数据，不包含业务。

Pros:

• 清晰的数据传输格式，解耦客户端和业务逻辑
• 可自定义格式，只返回需要的数据

Cons:

• 类 explosions，需要频繁创建 DTO
• 和客户端强耦合

BO(Business Object)

这些类封装了业务逻辑，实现了核心业务功能，可以组合复用 DO 和 DTO。

Pros:

• 封装复杂业务逻辑
• 可重用业务功能,避免代码重复

Cons:

• BO间依赖关系复杂,重构难度大

使用场景分析

Controller 层: 接收 DTO/VO 输入，返回 DTO/VO 给调用方

Service 层:
接收 DTO/VO 输入，使用 BO 执行业务逻辑，返回 DTO/VO

DAO 层: 使用 DO 与数据库交互

所以，Controller 和前端交互使用 VO/DTO，Service 层使用 BO+DO 封装业务，DAO 使用 DO 操作数据库。 这种分层和解耦有助于系统扩展与维护。