条件构造器
在前面学习快速入门的时候，练习的增删改查都是基于id去执行的，但是在实际开发业务中，增删改查的条件往往是比较复杂的，因此MyBatisPlus就提供了一个条件构造器来帮助构造复杂的条件。
MyBatisPlus支持各种复杂的where条件，可以满足日常开发的所有需求。
我们在快速入门中学习的使用MyBatisPlus的步骤中就需要继承BaseMapper接口，而在BaseMapper接口中有些方法的参数有些与众不同。
这些与众不同的参数是Wrapper类型的参数，那么Wrapper类型是什么呢？
Wrapper就是条件构造器，用来构造复杂SQL语句的，而Wrapper也不只是一个类，而是一个体系，Wrapper是最顶级的父类。
而下面的子类是AbstractWrapper，里面定义了大量方法，就如下图所示：
eq()就是等于，相当于SQL语句中where条件中哪个字段等于什么值。ne():not equal,不等于。gt()：great than，大于。ge()：大于等于。lt():小于。le():小于等于，...等等，只要是以前在where语句中写过的条件，在AbstractWrapper中都有对应的方法，也就是说原来的复杂条件都可以帮忙构造。
而在AbstractWrapper下面还有不少子类，而子类的作用就是继承兼拓展。
比较重要的子类分别是UpdateWrapper以及QueryWrapper
在父类AbstractWrapper中提供的方法已经将where语句后面的复杂条件构造完成了，而QueryWrapper就是在父类基础上拓展了select功能，允许在构造SQL语句时，还可以指定要查询哪些字段，因为在默认情况下是全部查询的，在这里是可以指定对应的字段的
与此类似的是，UpdateWrapper就是拓展类更新相关的功能，UpdateWrapper就是拓展了set语句后的复杂条件
而setsql()的参数是String类型，这里是让以字符串的形式将set的部分写出来，将来拼接到SQL语句中，在一些特殊的场景下会用到。
而结合这三个不同类型的wrapper，就可以去构造出各种各样复杂的增删改查的语句了。
而其他的三个子类和这三个类型的Wrapper名字几乎一样，都是多了一个Lambda。
AbstractLambdaWrapper，LambdaQueryWrapper以及LambdaUpdateWrapper。
他们的功能与前面的功能相差无几，无非是在构建条件时，基于Lambda特殊语法。
案例展示：基于QueryWrapper的查询
需求：
-
查询出名字中带O的，存款大于等于1000元的人的ID,username，info，balance字段。
SQL语句：
select id,username,info,balance from user where username like ? and balance >= ?利用MyBatisPlus中的条件构造器来实现：
void testQueryWrapper(){//1.构建查询条件 同时支持连式编程QueryWrapper<User> wrapper = new QueryWrapper<User>()//1.1.查询条件.select( "id","username","info","balance")// 1.2.范围条件.like( "username","o")// 1.3.排序条件 .ge( "balance",1000);//2.查询List<User> users = userMapper.selectList(wrapper);users.forEach(System.out::println);}测试结果：
-
更新用户名为Jack的用户的余额为2000
SQL语句
update user set balance = 2000 where username = "jack"利用MyBatisPlus中的条件构造器来实现：
void testQueryWrapper2(){//1.要更新的数据User user = new User();user.setBalance(2000);//2.更新的条件QueryWrapper<User> wrapper = new QueryWrapper<User>().eq( "username","Jack");//3.执行更新userMapper.update(user,wrapper);}测试结果：修改成功
案例展示：基于UpdateWrapper的更新
需求：更新ID为1,2,4,的用户的余额，扣200
SQL语句：
update user set balance = balance - 200 where id in (1,2,4)利用MyBatisPlus中的条件构造器来实现：
void testUpdateWrapper(){UpdateWrapper<User> wrapper = new UpdateWrapper<User>().setSql( "balance=balance-200").in("id",List.of(1L,2L,4L));userMapper.update(wrapper);}测试结果：
以上就是查询以及更新时利用条件构造器来完成，事实上不仅这两个，userMapper中除了新增以外，删除方法也可以使用条件构造器来构造复杂条件。
然后就是Lambda的Wrapper，实际上与普通的Wrapper功能基本一致，区别就在于：LambdaXXWrapper构建条件是是基于Lambda语法。为什要使用Lambda语法，因为我们在使用queryWrapper中字段名是写死的，这种写法属于硬编码的，耦合度较高，不太建议适用。
LambdaXXWrapper就是来解决这样的问题的。那么如何使用？
就以前面的两个案例来演示为例：
//1.构建查询条件 同时支持连式编程LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<User>()//1.1.查询条件.select( User::getId,User::getUsername,User::getInfo,User::getBalance)// 1.2.范围条件.like( User::getUsername,"o")// 1.3.排序条件.ge( User::getBalance,1000);//2.查询List<User> users = userMapper.selectList(wrapper);users.forEach(System.out::println);而LambdaXXXWrapper实质就是通过将写死的字段名转换成该字段对应的get函数即可，底层是通过反射机制得到该函数操作的字段名拿到，这样就不存在字符串硬编码了。只要是传字段名的时候都传递函数即可。
而在实际开发中也是推荐去使用这种Lambda开发模式的。
小结：
条件构造器的用法：
-
QueryWrapper和LambdaQueryWrapper通常是用来构建select、delete、update的where条件部分
-
UpdateWrapper和LambdaUpdateWrapper通常只有在set语句较为特殊时才使用
-
尽量使用LambdaQueryWrapper与LambdaUpdateWrapper，避免硬编码。
自定义SQL
自定义SQL并不是亲自去写SQL语句，而是利用MyBatisPlus的Wrapper来构建复杂的where条件，然后自己定义SQL语句剩下的部分。
即在SQL语句中，用Wrapper来做SQL语句的where部分，剩下的自己来写，也就是说，以前使用MyBatisPlus的时候，所有的SQL语句都是由MyBatisPlus来生成，等于是全自动，现在是只有Where部分由MyBatisPlus生成，相当于半自动。
那为什么要这么去做？
根据案例分析：
案例：自定义SQL
需求：将id在指定范围内的用户的余额扣减指定值。
完全手写SQL语句代码如下：
<update id = "updateBalanceByIds">update user set balance - #{amount} where id in <foreach collection="ids" separator =",",item ="id" open = "("close=")">#{id}</foreach></update>全部基于MyBatisPlus来实现的代码展示：
void testUpdateWrapper(){ UpdateWrapper<User> wrapper = new UpdateWrapper<User>().setSql( "balance=balance-200").in("id",List.of(1L,2L,4L));userMapper.update(wrapper);}这样看来全自动的非常方便，但是这里有一个问题：现在写的逻辑都是业务逻辑，将来时在service中去定义，这就相当于我们将SQL语句中的一部分写进了业务代码之中，这在很多企业的开发规范中是不允许的，他要求只能在Mapper层中xml文件中去定义SQL语句，因此全自动的写法也不能采用。
但是手写SQL语句的where条件非常复杂，代码量也可能非常巨大，但是如果我们用MyBatisPlus去编写where条件就会简单许多。因此更推荐使用MyBatisPlus来写SQL语句。
但是MyBatisPlus更擅长编写where条件，但是对于SQL语句的前半部分，在大部分情况下，MyBatisPlus也可以帮助我们书写，但是在一些特定情况下就较难实现。
比如前面的案例中的set语句并不是给字段赋一个固定的值，而是在原有值的基础上作数值运算，这属于动态变化的，只能在业务层中拼这条SQL语句，这就违背了企业的开发规范了，这就形成了矛盾。
而且这种矛盾不只是在更新语句中能够看到，在查询语句中也会存在。就比如在查询时调用聚合函数并且起别名，这样的MyBatisPlus就不能生成，只能在业务层中拼出来。这样又违背了企业规范。
为此自定义SQL应运而生：
既然MyBatisPlus擅长的是where条件的构建，一旦出现这种复杂的业务场景，就将where条件的构建交给mp去做，剩下的前半部分就去手动书写SQL语句即可。
但是这个手动书写不能再到业务层去拼接，需要将MyBatisPlus构建好的where条件往下传递，传递到Mapper层，在Mapper层中去拼接。
那具体如何实现这个传递与组装呢？
实现步骤：
-
基于Wrapper构建where条件
List<Long> ids = List.of(1L,2L,4L);int amount = 200;//1.构建条件LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<User>().in(User::getId,ids);//2.自定义SQL方法调用userMapper.updateBalanceByIds(wrapper,amount);-
在mapper方法参数中用@Param注解声明wrapper变量名称，必须是ew(这是一个固定的写法)
void updateBalanceByIds(@Param( "ew") LambdaQueryWrapper<User> wrapper, @Param( "amount") int amount);-
自定义SQL，并使用Wrapper条件
<update id="updateBalanceByIds">update tb_user set balance = balance -#{amount} ${ew.customSqlSegment}</update>这样就解决了之前说的问题，既保证了不在业务层编写SQL，遵循了企业规范，同时又享受到了MybatisPlus生成SQL条件的便捷特性。
进行测试：
检查数据库：
测试成功。
在哪些场景下可以用到自定义SQL？
-
SQL语句where条件之外的那些部分没有利用MyBatisPlus更方便的实现，而只能选择拼接，这时就可以使用自定义SQL。
希望对大家有所帮助，让我们一起努力。
