VODTO在spring boot2mybatis plus项目中之简单应用

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

1、单表最简单

直接Wrapperquery构建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对象，调用Wrappersquery查询；或者封装成入参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的条件查询，因为太爽了。对象查询可能会慢，但我们的时间更重要，不是吗？

最后，这是一篇水文。

类似如下代码就好

tmp=  tmpOrderByDescending<T, S>(orderByLambda)

                       Skip<T>((pageIndex - 1)  pageSize)

                       Take<T>(pageSize);

create table test

(

a varchar(20),

b varchar(10)

)

insert into test (b) values('b')

insert into test (a,b) values('','b')

insert into test(a,b) values ('a','b')

select case when a is null then b when a='' then b else a end from test

复制代码 ,粘贴,执行,直接可以看到结果

以上就是关于VO/DTO在spring boot2/mybatis plus项目中之简单应用全部的内容，包括:VO/DTO在spring boot2/mybatis plus项目中之简单应用、c# lambda如何查询指定的条数（就是全部数据的某段数据）、SQL中如何判断字段NULL或者为空字符串等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！