纯mybatis每个持久化操作都要写sql,会显得有些繁琐。现在市面上也有很多的插件,比如mybatis逆向工程,mybatisCodeHelperPro等,可以在xml文件中生成一些常用的sql和对应的mapper接口方法。也有一些mybatis的第三方工具框架,帮我们免去单表操作的sql编写,比如通用mapper,mybatis-plus。接下来我们来研究一下我个人常用的通用mapper的使用极其原理。
使用案例：
pom文件：
<dependency>
<groupId>tk.mybatis</groupId>
<artifactId>mapper</artifactId>
<version>4.1.5</version>
</dependency>
Springboot启动类：
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.transaction.annotation.EnableTransactionManagement;
import tk.mybatis.spring.annotation.MapperScan;
@SpringBootApplication
//这个注解不要导错了,要用tk.mybatis包里面的MapperScan
@MapperScan(basePackages = {"com.lb.springboot_simple_starter.mapper"})
@EnableTransactionManagement
@EnableScheduling
public class SpringbootSimpleStarterApplication {
public static void main(String[] args) {
SpringApplication.run(SpringbootSimpleStarterApplication.class, args);
}
}
Mapper接口:实现通用Mapper接口,并设置实体类泛型
public interface UserMapper extends tk.mybatis.mapper.common.Mapper<User> {
}
接下来我们可以看到Mapper接口已经具有很多方法
单表的增删改查都会有对应的api让我们调用,不用在xml中编写对一个方法的sql,如果不需要复杂的持久化操作,设置都可以不用建xml文件。
源码解析:
知识铺垫:
- mybatis源码
- @SelectProvider注解的工作原理https://www.jianshu.com/p/7e78ca14ef4a
首先不用多说,自己的Mapper接口凭空多了这么多方法,肯定是与我们继承他的通过Mapper接口有关系。来瞅瞅这个接口。
tk.mybatis.mapper.common.Mapper
可以看到他继承了很多其他的Mapper
1、 BaseMapper：提供增删改查的方法
2、ExampleMapper: 提供基于Example（条件）的增删改查的方法
3、RowBoundsMapper ： 提供分页的查询方法
Marker ：没卵用,是空的
下面我们就挑其中的BaseMapper<T>来看看
BaseMapper<T>
BaseMapper又继承了继承增删改查的另外4个Mapper
挑一个BaseSelectMapper接口看看
他又继承了SelectOneMapper<T>, SelectMapper<T>, SelectAllMapper<T>, SelectCountMapper<T>, SelectByPrimaryKeyMapper<T>, ExistsWithPrimaryKeyMapper<T>这么多接口,
==每一个传承至我们自己的Mapper的方法都对应着一个Mapper接口==
SelectByPrimaryKeyMapper
有一个selectByPrimaryKey的抽象方法,并且有SelectProvider注解
SelectProvider这个注解可以指定java类的某个方法来向mybatis提供对应的sql,其工作原理可以看看https://www.jianshu.com/p/7e78ca14ef4a这篇文章
那通用mapper是不是就是这样来实现这些方法的呢？
我们来看看注解中的method方法是不是会返回SQL
额,拉了跨,说好的sql呢,这是什么玩意。我当时就懵逼了,这绝对不是可以执行的sql吧,其实这个方法应该没卵用,那么对应的sql究竟是在哪构建的？
基于@SelectProvider注解的工作原理,我们知道mybatis初始化的时候,会在扫描完mapper.xml文件之后,扫描Mapper接口,有这个注解会生成一个MapperStatement对象,里面含有ProviderSqlSource对象,ProviderSqlSource对象有一个属性是指向提供SQL类的方法的。如何不做其他操作,现在这个dynamic方法没法提供实际的作用,是不是在tk.mapper初始化的工程中,改变了ProviderSqlSource指向java方法的对应属性值呢。接下来我们去他的初始化流程去寻找答案。
tk.mapper初始化:
入口@MapperScan
这个注解会@Import进来一个tk.mapper的扫描器
MapperScannerRegistrar实现了spring的ImportBeanDefinitionRegistrar接口,那么实例化的时候,会调用registerBeanDefinitions方法来导入其他的bean。这里其实就是导入其他Mapper接口
说句实话,这个方法的代码和mybatis-spring里面mybatis扫描mapper接口的代码几乎一模一样,干的事也基本一摸一样:
创建一个扫描器,开始并扫描Mapper接口并注册BeanDefinition
调用doScan方法
这个扫描器肯定继承了ClassPathBeanDefinitionScanner接口（和mybatis-spring里的也一模一样），并重写了doScan方法和isCandidateComponent
doScan：里面会直接复用父类自带的doScan方法,因为这就是spring扫描包中的bean的方法
isCandidateComponent:这个方法也必须得复写,这个方法会在扫描到需要注册到spring的beanDefinition后悔进行一次过滤,接口和抽象类是会被过滤的,它复写了这个方法之后,使得Mapper接口被封装成beanDefinition,进而可以创建Bean。
扫描到Mapper接口并封装成BeanDefinition
之后会调用processBeanDefinitions对BeanDefinition进行一些修改
这段代码其实也mybatis-spring中的大体一致。
更改BeanClass,
设置autowired-mode = by type,使得SqlSeesionTemplate可以作为MapperFactoryBean的属性注入进来
不同点:
- BeanClass不是mybatis-spring中的MapperFactoryBean了，然后tk.mapper中的,其他的属性都是用的mybatis里面的。
- 多了个mapperHelper属性会被注入进来
好了,扫描Mapper的工作到此为止,接下来就是Mapper接口的实例化了。
Mapper 接口实例化:
上面讲到Mapper接口的BeanDefinition的BeanClass被改成了tk.mybatis中的MapperFactoryBean。那么实例化的工作主要会由这个类(实例化出另外一个Bean来替代原始的Mapper接口的Bean)来完成。跟mybatis扫描注册Mapper是一样的原理。
MapperFactoryBean
最终实现了InitializingBean接口,那么spring会调他的afterPropertiesSet方法
调用到自身的checkDaoConfig()
方法下面就会用之前注入的mapperHelper来做一些事情
现在有个问题哈,就是mybatis-spring他也在扫描xml文件(因为@MapperScan是tk.mapper的,所以没有扫描接口)
mybatis-spring扫描xml文件:
会把xml文件里的select|update|delete|insert封装成MapperStatement对象放在Configuration对象里,
会根据xml的nameSpace扫描Mapper接口的select|update|delete|insert|SelectProvider注解，封装成MapperStatement对象放在Configuration对象里。
看看mybatis扫描Mapper接口中的@SelectProvider的结果
可以看到指定的java类方法就是tk.mapper接口方法的@SelectProvider所指定的,所以接下来这个过程,tk.mapper会改变这个sqlSource的值。
获取MapperTemplate对象
这里有很多提供了方法的上层Mapper,作为key,value是对应的SelectProvider,SelectProvider都继承了MapperTemplate类。
每个SelectProvider内部都会维护一个map,映射支持处理的方法,
我们看看SelectByPrimaryKeyMapper对应的SelectProvider对象里的methodMap维护的是啥,
这个方法的逻辑就是遍历registerMapper（map）所有的value值,分别调用supportMethod方法，找到MapperStatement所对应的BaseSeleteProvider。这里返回的就是SelectByPrimaryKeyMapper对应的BaseSeleteProvider
然后调他的setSqlSource方法
先从MapperStatement的id取出方法名
其实就是留下 . 后面的就是方法名了
根据方法名,从该类内部维护的methodMap中取出method对象
现在该类是BeseSelectProvider,方法是selectByPrimaryKey,返回调用它，获取到了带mybatis标签的sql片段
之后就是根据sql片段,创建DynamicSqlSource,并替换掉MapperStatement中原来那个无用的ProviderSqlSource
反射调用MappedStatement的setSqlSource方法()
所以,到此,SelectByPrimaryKeyMapper这个Mapper接口方法已经有了MapperStatement,MapperStatement中的SqlSource也在上诉过程中替换成了一个具有可执行的sql的SqlSource.和mybatis扫描mapper.xml文件中创建的MapperStatement和SqlSource具有同样的功效！
总结:
和mybatis的关系:
- 在不影响mybatis原有功能的情况下,很好的拓展了mybatis的功能
- 扫描xml的工作依旧由mybatis来完成,再次扫描并注册mapper接口的功能以拓展的方式由tk.mapper复写,扫描后的结果依旧存放在mybatis的Configuration中，和mybatis自己扫描mapper接口的代码逻辑几乎一致,唯一添加的功能就是,对mybatis的Configuration中的由自己拓展的方法对应的MapperStatement的sqlSource进行更改,以此来提供具体可执行sql
- 后续执行持久化方法,依然是mybatis的代码功能,tk.mapper仅在扫描mapper接口阶段提供了SqlSource
