一、快速入门
一句话总结——
MP是专注单表的CRUD工具箱。mybatisPlus是mybatis的最好的合作伙伴,二者要结合使用。
(一)特点
润物无声
只做增强不做改变,引入它不会对现有工程产生影响,如丝般顺滑。
效率至上
只需简单配置,即可快速进行单表CRUD 操作,从而节省大量时间。
丰富功能
代码生成、自动分页、逻辑删除、自动填充等功能一应俱全。
(二)入门案例
一、原生mybatis
Mapper映射文件,主要就是用来配置SQL映射语句的,根据不同的SQL语句性质,要使用不同的标签来包裹。
还要逐一在XML文件里面写方法,很麻烦
二、引入mybatisPlus后
1.引入MybatisPlus的起步依赖
2、自定义的Mapper继承MybatisPlus提供的BaseMapper接口
直接可以开始使用MP里面的方法了——
(三)常见注解
1、原理——通过反射+约定大于配置实现CRUD
继承自BaseMapper<>泛型之后,指定了泛型之后,MP就可以通过反射拿到实体类的字节码信息,生成实体类
2、如果实体类不符合定义就需要自定义配置表名、字段名
3、通过注解自定义
@TableName:用来指定表名
@Tableld:用来指定表中的主键字段信息
注意默认的生成ID是雪花算法(很长的Long型)
@TableField:用来指定表中的普通字段信息
4、代码实践
5、总结
(四)常见配置
问题引出——
前面的是mp自身默认支持的,不过mp也支持用户自定义配置,这节课了解用户自身配置的知识。
常见配置
YML文件涉黄等价于没效果
(五)MP完整流程
二、核心功能
(一)条件构造器
推荐使用lamabdWrapper的语句
总类图
所有复杂where条件都有方法可循
AbstractWrapper
QueryWrapper
UpdateWrapper
结合以上已经能够写出各种复杂的CRUD功能了
传统的条件查询
使用MP的条件语句
查询
模糊查询like
更新
复杂语句
lamabdwrapper——基于函数式的where条件
(二)自定义SQL
一、问题引出——
1、耦合在业务代码中
使用完全的自动化代码生成器有一个问题是在于我们的Sql语句嵌入到Java业务代码之中了,这在企业开发之中是不允许的。企业中只能在Mapper层或者Mapper.XML 层去定义Sql语句,所以很有自定义Sql语句的必要,然后独立于业务代码——解耦。
2、复杂情况不能构建
我们可以利用MyBatisPlus的Wrapper来构建复杂的Where条件,然后自己定义SQL语句中剩下的部分。
二、3步自定义Sql语句+where拼接
我们可以利用MyBatisPlus的Wrapper来构建复杂的Where条件,然后自己定义SQL语句中剩下的部分
1、基于Wrapper构建where条件
2、在mapper方法参数中用Param注解声明wrapper变量名称,必须是ew
3、自定义SQL,并使用Wrapper条件
以上既保证了不在业务层编写Sql代码,遵守企业规范,又又享受了MP生成where语句的便捷的特性
(三)Service接口
1、方法一览
(1)总的方法
(2)查询单个数据
(3)查询多个数据
(4)分页查询
(5)查询数量
(6)保存或新增
(7)删除
(8)lamabd接口的复杂查询
2、代码实现
(1)流程图
(2)首先业务IUserService接口继承IService接口
(3)其次业务实现类UserServiceImpl里面实现业务接口并且继承实现了IService接口的所有方法的类ServiceImpl
补充一下::的使用
3、总结Service接口使用流程
MP的Service接口使用流程是怎样的?
(四)IService开发基础业务接口
问题引出——
MP中的basemapper与IService里面的方法有很多功能都是一致的,那么实际开发中怎么用呢?
接下来就来实际开发,自定义controller、Service一直往下
(1)基于Restful风格实现下列接口
注意一
表达提交需要有表单的DTO实体,接口返回要有VO实体
有关VO、BO、DTO、DAO、PO等点击这里
注意二——Swagger
Swagger配置
在前后端分离开发中,Swagger2可以帮助开发人员设计、构建、记录和使用RESTful Web服务,仅用注解就可以将代码和文档融为一体,大大减少了与其他团队的沟通成本。下面我们用SpringBoot来配置swagger2
(2)需要配置的Swagger信息
配置文件解读——
注意三——注入字段的推荐性
这里推荐使用final+@RequiredArgsconstructor注解将来只有加了final的字段才会被注入。
这里推荐使用final+@RequiredArgsconstructor注解将来只有加了final的字段才会被注入。
(3)实操
一、简单逻辑业务
简单操作直接在controller层写了
新增(DTO->PO)
删除
根据ID查询(PO->VO)
二、复杂业务
自己编写Service层,与controller层分离——
controller层——
Service层——定义业务
basemapper——自定义方法
swagger操作——
三、总结MP的业务开发流程
①若是简单的CRUD,直接利用MP的功能,Mapper层根本用不上
②若是复杂的业务,在业务层里面写业务流程逻辑,同时使用MP的CRUD
③若是复杂而且数据库操作不是简单的CRUD时,在Mapper层写Sql语句,这时有两种解决方案——
1、在Mapper层使用注解写简单的Sql语句
2、在Mapper.xml文件层写复杂的Sql语句
(五)IService的Lambda查询(lamabdQuery)
eq、ne、gt、lt、ge、le分别代表含义
问题引出与需求——
需要条件判断的时候,业务就很长,比如下面的——
这就是lamabd查询的用武之地了——
注意这里参数太长,可以直接定义一个对象来接收——
在业务层编写查询SQL语句
有list()、one()、count()、page()等多个后缀,返回多个、单个、数量、页查询等
可以看到使用lamabd的条件查询很好用——
(六)IService的Lambda更新(lamabdUpdate)
原来的实现——
现在的实现——
注意最后一定要加上Update方法,否则不会执行。
(七)IService的批量查询
传统用法for耗时——结果耗时210000ms
批处理耗时——结果耗时20000ms
提升了10倍
以上解析——
传统的for——因为每次与数据库访问就有一次网络请求,所有与数据库的访问频次越低越好。
批处理——将每1000次请求变为一次,但是这一千条预编译的Sql语句还是每一条每一条的在数据库中执行的,也对性能有所影响。
最佳方案——
将Sql语句组装成下面的样子就只有一次提交了。