在我使用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的条件查询，因为太爽了。对象查询可能会慢，但我们的时间更重要，不是吗？
最后，这是一篇水文。
