mapstruct对象转换工具

mapstruct是一个基于java注解生成类型安全bean的转换工机；

ps:最好可以和 lombok 一起使用

一般情况下，将do转换为dto，需要进行一下 *** 作：

类PersonDo:

类PersonDto：

方法进行转换：

使用mapstruct：

引入依赖的包：

pom.xml

定义转换mapping接口：

PersonDo2DtoMapping.class

在编译后class目录中会自动生成该接口的实现类（idea中为target目录）：

PersonDo2DtoMappingImpl.class

定义主函数测试：

以上是mapstruct的基本转换功能。

还有一些可配置的功能：

PersonDo2DtoMapping.class

编译后：

PersonDo2DtoMappingImpl.class

PersonDo2DtoMapping.class

PersonDo2DtoMappingImpl.class

测试：

有时我们需要int转boolean（带有语义的转换，比如age转换为是否成年）。那么我们就可以定义转换规则，或定义默认的转换方法。先说下定义转换规则方式。

PersonTransRule.class

在mapping中引入规则：

使用mapper注解的uses属性，参数类型为class数组，可以指定多个转换规则类。

PersonDo2DtoMapping.classs

编译后的文件：

PersonDo2DtoMappingImpl.class

测试：

依赖依然是上面说的两个包。

只需要在映射接口的mapper注解中添加参数componentModel = "spring"

PersonDo2DtoMapping.classs

编译后生成的实现类：

PersonDo2DtoMappingImpl.class

在使用该映射转换的时候只要使用@Autowired注解注入就ok。

在我使用mybatis plus开发的项目中，总结出几条经验：

1、单表最简单

直接Wrapper.query构建QueryWrapper查询对象，也可以通过集成Model，得到一系列的加强功能，可以说单表 *** 作，其灵活性和简便、性能，和JPA一样牛B（我用过一段时间的JPA，使用repository查询也很方便）。

在Controller层，VO常常被我用来简化返回的对象，毕竟BeanUtil还是挺好用的，追求性能的话，恰好IDEA有个插件可以很好的实现手动版赋值拷贝。

DTO再单表 *** 作的时候，作用就不是那么的明显了，为了偷懒，一个VO跑所有，我知道不好，没办法就是懒。

简单总结：单表 *** 作，vo，dto主要用来简化对象的属性，不能一个请求连User的password都丢出去吧，明文密码的现象有木有。

2、联表查询

使用Mybatis plus联表查询，基本上就退回到mybatis的层面了，VO/DTO这个时候就算是比较好的补充了，反正有的人喜欢SQL,有的喜欢对象 *** 作，还有注解型、xml型，玩法真多。

A、一对多的场景：

Controller(使用VO接收和返回，基本上可以做到一个请求完成所有需要的data)，当请求到达Controller后转发给Service，使用我们可以开始拆分成不同的dto来使用了。Service入参的时候，有两个选择：从VO提取需要的参数封装成Map对象，调用Wrappers.query查询；或者封装成入参DTO，方便复用，这里根据场景选择；返回时DTO就有必要了，一边来说，到了Service层我们不会考虑数据脱敏等安全问题，我们考虑性能。您可能会说，不该mybatis的默认service返回的都是数据实体对象，装DTO岂不是浪费，NONono,喜欢SQL的同学对dto一定是喜欢的不得了，返回DTO不至于出现数据实体的残躯（属性缺胳膊少腿）。喜欢默认Service的同学，看好了，我说的是一对多的场景，我给点提示"多线程"，将无数个小DTO通过并行的方式，拷贝给VO实行组装，速度提升不是的一两点，特别是一个好大的页面请求，还有别忘记“同步锁”。那种CPU狂飙的感觉，爽。

B、多对多（不常见）

见过意大利面吗，一团一团，前台的同学，一个form请求过来，可能连参数名都对不齐。一般情况下，我建议大家直接拒绝请求。但如果对方付了RMB的话，（比如你是一个接口商），我们还是要勉强抬抬眼皮的。多对一的场景出现在一个不常见的场景，比如说：我们的接口需要一次接收多个对象组装的data，第一选择，拆成小dto，传给各自的mapper，返回的时候组装自己的VO。第二选择，BeanUtils又来了，属性拷贝走起Wrppers查询，再用VO封装；第三选择，性能最好的，写SQL。他们丢再大的参数我也不怕了。

总结：

VO：简单的时候可以替代dto从前跑到后；

DTO：只在Service,mapper层跑；

要会拆，能拆。充分利用mybatis plus的条件查询，因为太爽了。对象查询可能会慢，但我们的时间更重要，不是吗？

最后，这是一篇水文。

你好，按照标准来说：

1、entity里的每一个字段，与数据库相对应，

2、dto里的每一个字段，是和你前台页面相对应，

3、VO，这是用来转换从entity到dto，或者从dto到entity的中间的东西。

举个例子：

你的html页面上有三个字段，name，pass，age

你的数据库表里，有两个字段，name，pass(注意没有age哦)

而你的dto里，就应该有下面三个(因为对应html页面上三个字段嘛)

private string name；

private string pass 

private string age

这个时候，你的entity里，就应该有两个(因为对应数据库表中的2个字段嘛)

private string name；

private string pass

到了这里，好了，业务经理让你做这样一个业务“年龄大于20的才能存入数据库”

这个时候，你就要用到vo了

你要先从页面上拿到dto，然后判断dto中的age是不是大于20，如果大于20，就把dto中的

name和pass拿出来，放到vo中，然后在把vo中的name和pass原封不懂的给entity，然后根据

entity的值，在传入数据库，这就是他们三个的区别

PS，VO和entity里面的字段应该是一样的，vo只是entity到dto，或者dto到entity的中间过程，如果没有这个过程，你仍然可以做到增删改查，这个就根据具体公司来的，纯手打，望采纳

---