在使用mybatis-plus时，大家是怎样处理查询结果转成VO的？

Question

之前都是直接用Mybatis的，最近开始尝试用MP。

例如我有一个用户实体UserEntity，里面有用户名、密码、生日等等字段，现在我只需要查出用户名和密码，我可能封装一个AccountVO。但是MP查询出来的结果，要么是实体类型、要么是Map类型，想利用链式查询的便利，但是查询出来的实体类型还得手动转成Vo，就像下面这样：

       UserEntity userEntity = lambdaQuery ().eq (UserEntity::getId, "1")
                .select (UserEntity::getUsername, UserEntity::getPassword)
                .one ();

        return new AccountVo ()
                .setUsername(one.getUsername ())
                .setPassword (one.getPassword ())；

感觉这样写太蠢了，要是只有一两个属性要设置还好，要是每个实体都有十几个属性要这样手动的转换，不得写吐了。

况且正常开发过程中，很少有情况直接查个Entity就OK的吧，一般都得对查询结果封装成VO啥的屏蔽多余的属性。要是用Mybatis直接XML里写个SQL，字段名不一样的可能写个ResultMap，查出来的结果就是VO。但是MP里查出来的直接就是个实体，要么就是Map，感觉太鸡肋了，没人会想直接把Entity或者Map返回给前端吧。要是这种简单的查询还得走XML，我实在找不出用MP的理由。

想问下大家对于这种情况有没有更加优雅的写法。

Answer 1

回来填坑，就目前个人的实践经验来看：

1. 能手动转换的尽量手动转换。这样可以避免很多问题，例如属性要改名字，直接放心大胆的用IDEA重命名就行了，可维护性更高。缺点也很明显，代码里一大坨这样的纯胶水代码，写起来是真的麻烦（推荐idea allset插件、列编辑操作），看起来是真的难受。

2. 可能能重用的bean转换代码，尽量写成适配器类。同样是手动转换，但是这种方式可以避免在业务逻辑里看到一大堆bean转换的胶水，看起来更舒服。缺点就是书写过程更加麻烦了，而且很多这种代码并不能被重用。

3. BeanWapper。BeanWapper可以用于实现一些特殊且可复用的bean属性转换逻辑，例如一个bean属性的类型在另一个bean中变了。

4.BeanUtils。最大的优点，简单。最大的缺点，可维护性差。名字不一致BeanUtils就无能为力；某个属性一旦重命名，99%带来会出现大问题，可维护性极差。

综上：强烈推荐手动转换、尽量把转换代码封装写成适配器方法，特殊且可复用的bean属性转换逻辑使用BeanWapper，BeanUtils千万慎用。

Answer 2

自己封装一下查询结果到VO的转化吧，之前公司都是有相关组件可以直接完成相关的转化

Answer 3

BeanUtil 啊

Answer 4

mapstruct可以供你参考下，性能肯定是保证不了的，
但是话说回来了，现在的这种量级，包括beanUtil是微乎其微的

Answer 5

1.建立一个vo，你可以把你本来返回的实体复制去掉一部分不要的属性，把要的属性粘贴到新的类，这个就是新的vo了，然后返回的时候指定这个vo即可

Answer 6

基于反射封装一个转化工具类咯

Answer 7

我就是用BeanUtil，不知道现在楼主现在怎么弄了

Answer 8

使用mybaitis-plus做查询都不使用queryWrapper的吗？
直接

 public Company search(String username) {
        QueryWrapper<Company> queryWrapper = new QueryWrapper<>();
        queryWrapper.eq("user_id",username);
        queryWrapper.select("列名1","列名2");
        return companyMapper.selectOne(queryWrapper);
    }

Answer 9

在Entity实体类上按如图方式添加非数据库字段即可，望采纳