对于详情的接口也是有一定的门道的-这个详情开发量大的根本原因是数据不统一呀-我还是第一次处理这样的问题-略感复杂-有提升

public R queryByIdWithSupervise(@RequestParam(value = "id") Long id) {
    IocarFeeEntity byId = iocarFeeService.getById(id);
    if (ObjectUtils.isEmpty(byId)) {
       return  R.ok("该收费单不存在");
    }
    LambdaQueryWrapper<IocarSuperviseEntity> queryWrapper = new LambdaQueryWrapper<>();
    queryWrapper.eq(IocarSuperviseEntity::getFeeId, id);
    IocarSuperviseEntity iocarSuperviseEntity = iocarSuperviseService.getOne(queryWrapper);
    if (!ObjectUtils.isEmpty(iocarSuperviseEntity)) {
       //换一种写法更好-两个实体放到一个vo里面 但是前端解析会麻烦一点
       IocarFeeSuperviseVo iocarFeeSuperviseVo = new IocarFeeSuperviseVo();
       BeanUtils.copyProperties(byId,iocarFeeSuperviseVo);
       BeanUtils.copyProperties(iocarSuperviseEntity,iocarFeeSuperviseVo);
       return  R.ok(iocarFeeSuperviseVo,"查询成功");
    }
    return R.ok(byId);
}

public class IocarFeeSuperviseVo {
feeEntity feeEntity；
SuperviseEntity superviseEntity；
}

当时想不到这一点

开发的太少了

你写详情接口不要用原来的逻辑-在原来的逻辑上添加查询的性能就会降低

很消耗服务器资源

这个查询接口使用非常频繁

如果每次都是这样的多一个查询

问题很严重的

开发就老老实实的开发

不要偷懒 不然维护起来也很麻烦的

开发的时候多写一个接口没啥的-不要想着复用

这样会导致你的代码越来越复杂 

每个功能都有自己的一套增删改查逻辑

这样就很清晰修改也方便

返回结果不一致

前端处理也很麻烦

一个页面的数据来源 尽量统一成统一个接口

这样处理返回结果 逻辑更清晰

还能降低很大的开发量 方便维护

之前真的很傻 ，写了那麽多没用的代码

数据做好校验

这个开发量大的根本原因是数据不统一呀

将不同的数据来源统一到同一个接口里面

我还是第一次处理这样的问题

如果之前都是用的很笨的方法（不用实体 自己一个一个字段加 太傻啦）

之前重心都跑偏了 把时间都用在写vo上面了 

封装vo可以大大降低工作量

遇到这种稍微复杂一点的场景

开发起来就会感觉吃力

平时多想一些简单的方法

要保证自己写的接口不乱 别人用起来方便 这才是水平