pojo之vo_dto_po的一些理解

根据这几篇文章，我觉得最重要的是要找知道其概念或定义。如果难以理解，就用实际案例去类比搞清楚概念以及使用。

看了这些文章，我觉得vo是返回给前端的数据，该vo对象定义了该页面的字段等格式，是一种标准也是一种规范。

vo的效果达到极致的情况下，该vo就是要展示的对象，前端拿到这个vo不需要处理就可以直接将该vo放到前端组件让页面展示该vo对象。这种情况下前端不需要对后端传来的对象进行解析处理，因为这个vo对象就是要进行展示的对象。这就是极致情况下的vo。

不过一般前端也不是每次都可以将后端返回的response直接扔到页面上解析展示，一般前端接收到后端的请求都会需要微处理一下才能传递给前端的组件或标签的属性。

实际上很多公式开发并没有怎么严格规范，所以这些对象在使用的时候并没有太严格来遵守这种开发规范的。毕竟又没说不规范就要扣钱是吧，所以你爱咋写就咋写，随你舒服就行，既然这样，就难免出现不规范的问题，老鸟不遵守了，那么新鸟一旦入职，看老鸟代码乱糟糟的，那可能随大流也没怎么规范了，慢慢地可能就看到很多不可思议的类放到不同的层或包里。

po：（Persistent Object）Persistent 是持久化的意思，持久化对象我们可以联想到数据库的数据。在内存里的数据如果不持久化到数据库或磁盘上，那么一旦宕机就会来不及保存内存的数据。那么数据库一般都是表来存储多行数据，这些数据都在数据库服务被进行了持久化，那么每一行数据实际上就是映射对应着一个po对象。

dto对象：（Data Transfer Object）介于po到vo之间的对象，它是用来干什么的？假如说在数据库查到了一行数据，

该行封装成为po对象，但是有很多属性是不需要的，那么就可以拿去拷贝有效属性（实际上需要用到的属性），这些由有效属性的数据就可以被封装成为一个dto对象；又或者是所需要的属性较多，一个po对象的所有属性是不够用的，于是就将一个po对象的所有属性都拷贝到一个dto对象，然后再去通过业务处理来补充dto其他的属性。

这些都经常在controller层和service的impl实现类能够看得到，例如：

controller层的：

java 复制代码

@GetMapping("/{id}")
public R<DishDto> get(@PathVariable Long id){
    DishDto dishDto = dishService.getByIdWithFlavor(id);
    return R.success(dishDto);
}

在例如service层的impl实现类：

java 复制代码

@Override
public DishDto getByIdWithFlavor(Long id) {
    Dish dish = this.getById(id);
    DishDto dishDto = new DishDto();
    BeanUtils.copyProperties(dish,dishDto);//这里是拷贝有效的数据
    LambdaQueryWrapper<DishFlavor> queryWrapper = new LambdaQueryWrapper<>();
    queryWrapper.eq(DishFlavor::getDishId,dish.getId());
    List<DishFlavor> dishFlavors = dishFlavorService.list(queryWrapper);
    dishDto.setFlavors(dishFlavors);//填充其他的属性
    return dishDto;//dto对象作为结果返回给controller层
}

小结：

vo一般就用来返回前端的data里面的数据或后端接收前端controller的数据。

dto一般就处理service层的内容吧，主要是讲po对象进行封装

一般呢，你要是公司的项目的话，那么你一般就是从1-n，这是大多数的情况了。

而从0-1的情况很少了，除非你是全职才有可能遇到，不是实习那种哦。

如果是对于中小公司的话，那么大致理清楚一些内容就可以些项目了。先这样吧。

如果是个人项目，那就自己再去调研仔细些再全面些吧，因为这篇文章是基于目前我实习的感悟写的，也没些的很严格很区分的开。调研的文章也没发现有区分得多清晰，也许这种东西本身就是规范，所以没有很严格的规矩，所以还没找到足够全面的一些示例。