在使用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千万慎用。