深入理解Java Web开发中的PO、VO、DTO、DAO和BO概念

原创已于 2024-07-01 08:55:52 修改 · 2.3k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#java #后端 #mvc

于 2024-04-06 17:53:23 首次发布

本文详细解释了VO、DAO、DTO、PO和BO在软件开发中的角色，涉及数据传递、业务逻辑分离、数据库交互等内容，展示了它们如何帮助简化前端与后端之间的数据处理和减少代码冗余。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

名词解释

首先说VO（View Object）😊 这个最好理解了

也有人说这是Value Object 这个就自行斟酌了但说的都是一个东西

就是后端返回给前端的数据都是VO对象

那为什么会有这一层呢? 为什么数据库返回的数据不直接返回给前端?

首先vo层还是很有必要的比如说数据库有这么一个性别字段sex

0 表示女👰
1 表示男👱
2 表示保密👽

{
"name": "Likefr",
"sex": 0 // 女
// ...
}

以上是数据库查询出来的数据这么直接将数据返回给前端的确没有问题😅 前端判断sex的值在页面显示男女亦或者是保密

但是现在我们会根据不同门户返回不一样的字段比如

A页面希望服务返回的性别字段不再是sex而是gender

B页面希望服务返回的姓名字段是nickname

再或者某个页面要求C服务返回的性别值不再是 0 、1 而是 🙇帅哥、或者🙅美女

其次VO层还能有效避免泄露我们数据库真实的字段如:

数据库年龄字段 age
vo层年龄字段 year

回到设计层面服务层(Service)只负责处理业务数据 ,而视图层(Controller)展示层负责渲染我们的数据

命名实例: UserVo ProcudtVo

随便说一嘴服务层返回的数据如果需要有VO层则需要new xxxVo 然后setXX 去赋值
这会增大代码量我这边推荐这两种

spring beanutils属性拷贝
mapstruct

个人是喜欢 mapstruct实体映射

DAO又是什么?🚒

其实就是mapper 和数据库直接打交道

@Mapper
public interface SysUserMapper extends BaseMapper<xxxPo> {}
// 熟悉的不能在熟悉了吧?

这一层实在服务业务层面与数据库中间也就是在 service 具体实现里边注入 xxxMapper 然后执行调用mysql 返回数据

那么该类继承的BaseMapper<xxxPo>又是什么？
xxxPo 一会下面会单独说 🅰🅰🅰
BaseMapper 是mybatis包下的一个基类包含了常用的增删改查😾

在这里插入图片描述
如果还不能满足我们的需求我们也可以自定义自己的需求步骤如下:

mapper内声明一个接口
编写xml文件实现这个接口去执行我们的mysql

命名规范：一般都是xxxMapper 或 xxxDAO

DTO (数据传输对象)🚃

DTO 这个我不多说他有很大歧义😌

他有几种存在的形式：

controller 层定义dto用来接收前端传过来的参数
dto 类声明一些数据库不存在的字段这些字段的意义就是业务层处理过后的数据方便数据交互
把dto 当作vo来使用返回给前端

命名规范： xxxDTO (xxx为业务领域相关的名称)

PO(持久化对象)🚀

PO等同于Entity 需要实现Serializable接口

public class UserPo implements Serializable {}
// 或
public class User implements Serializable {}

这个PO里的字段与应数据库的字段一一对应
一个PO就对应数据库的一条记录
正常来说不会出现与数据库表无关紧要的字段😼

🅰🅰🅰
还记得上面的dao吗?

public interface SysUserMapper extends BaseMapper<**xxxPo**> {}

泛型xxxPo通过基类BaseMapper中的方法,结合PO对数据库进行相关的操作
比如查询用户表那么就返回UserPo 这个实体

BO Business Object（业务对象）🚬

BO = DAO + 业务方法, 在原先DAO的基础上添加业务方法,形成BO对象。

主要用于封装复杂业务逻辑😵、用的比较多的封装到bo实体中

简单的说BO就是针对实体中对数据进行检索或处理的对象

就比如有这么一个订单BO实体

public class OrderBO {
    private Long id;
    // 商品列表
    private List<Product> products;
    // 价格
    private BigDecimal totalPrice;

    // 构造函数、getter 和 setter 略

    // 计算订单总价
    public void calculateTotalPrice() {
        // 根据订单中的商品计算总价
        totalPrice = BigDecimal.ZERO;
        for (Product product : products) {
            totalPrice = totalPrice.add(product.getPrice());
        }
    }

    // 提交订单
    public void submitOrder(User user) {
        // 执行提交订单的业务逻辑
        // 可能包括库存检查、订单状态更新等操作
    }

    // 其他业务方法...
}

BO中的业务方法仅仅是针对一个同一个实体对象，如果BO里的方法体处理逻辑涉及到有多个实体对象，则方法应该放在Service接口中并实现

bo 实体类支持序列化和反序列化, 这就很方便的流通只需要反序列化后即可调用内部方法和工具类一样

这么解释我不知道你是否能明白?😳😳😳

DO

DO 在业界有两个版本🌟🌟🌟
一个是阿里巴巴的开发手册中的定义 DO（ Data Object）(数据对象)🌻

和mysql表字段相同
这个通常是个数据传输对象
和业务逻辑无关
主要关注数据的结构和传输

这个等同于前面的PO

另一个是在DDD（Domain-Driven Design）领域驱动设计中 DO（Domain Object）🍄

与数据库结构无关
主要关注业务

这个等同于上面的BO

最后看到标题这么多o也不要慌他们都可以统称为pojo

那什么是pojo 🙀？

POJO 是指普通的 Java 对象（Plain Old Java Object）
大白话就是很简单的一个类很简单很简单的一个类💪

那么怎么才能算是一个pojo类呢? 下面是他的定义

没有继承任何类
没有实现任何接口
不依赖任何注解
有一些private字段的属性
只包含get set 方法

public class User {
    private String username;
    private String email;

    // 构造函数
    public User() {
    }

    public User(String username, String email) {
        this.username = username;
        this.email = email;
    }

    // getter 和 setter 方法

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    // toString 方法
    @Override
    public String toString() {
        return "User{" +
                ", username='" + username + '\'' +
                ", email='" + email + '\'' +
                '}';
    }
}