啃了一周tkmybatis源码&＃xff0c;留篇文章记录下&＃xff0c;阅读时间30分钟-1个小时
纯mybatis每个持久化操作都要写sql,会显得有些繁琐。现在市面上也有很多的插件,比如mybatis逆向工程,mybatisCodeHelperPro等,可以在xml文件中生成一些常用的sql和对应的mapper接口方法。也有一些mybatis的第三方工具框架,帮我们免去单表操作的sql编写,比如通用mapper,mybatis-plus。接下来我们来研究一下我个人常用的通用mapper的使用极其原理。
tkmybatis源码版本&＃xff1a;
tk.mybatis
mapper-spring-boot-starter
2.1.5
目录
一、使用案例&＃xff1a;
二、整体流程&＃xff1a;
三、源码解析:
1、Mapper接口扫描:
a、接口扫描入口位置
b、创建扫描器并利用MapperScan参数初始化该扫描器
c、注册扫描器filter
d、调用doScan方法扫描mapper
e、使用processBeanDefinitions对扫描出来的mapper的BeanDefinition进行一些修改
2、Mapper 接口Bean的实例化:
a、关键属性注入
b、SqlSessionFactory初始化操作内容
c、为每个方法对应的MappedStatement更新SqlSource
3、将Mapper实例注入到依赖该实例的bean中
4、实际SQL语句的执行
总结:
一、使用案例&＃xff1a;
参考《tkmybatis-02-SpringBoot整合TkMybatis》
二、整体流程&＃xff1a;
tkmybatis流程大概分为以下几步&＃xff1a;
-
根据properties文件中配置的xml位置&＃xff0c;为每个mapper接口生成一个MappedStatement对象(此时对象的SQLSource为不可执行的Provider)
-
根据ScanMapper接口, 将接口加入到Spring 容器中&＃xff0c;创建对应的BeanDefinition&＃xff0c;然后修改BeanDefinition中的Bean类型为MapperFactoryBean
-
Spring容器实例化MapperFactoryBean实例&＃xff0c;在初始化方法中&＃xff0c;获取第一步每个接口生成的MappedStatement对象&＃xff0c;并将MappedStatement对象的SQLSource修改为可执行的SqlSource&＃xff08;Provider生成xml格式的SQL&＃xff0c;根据该SQL利用languageDriver创建新的sqlSource&＃xff09;
-
将mapper的bean实例注入到需要依赖该实例的service中&＃xff0c;此时会Spring容器调用MapperFactoryBean的getObject方法&＃xff0c;该方法创建了一个mapper的代理类&＃xff08;使用jdk的动态代理方法&＃xff09;&＃xff0c;并注入到service里面去
-
执行SQL时&＃xff0c;对mapper的SQL操作&＃xff0c;都由mapper的代理类mapperProxy来实现&＃xff0c;实现过程跟原生mybatis用sqlsession创建的代理类一样的&＃xff0c;只是这里没有显示的使用sqlsession来创建代理类&＃xff0c;而是放到了MapperFactoryBean的getObject里面&＃xff0c;将生成的代理类注入给service
三、源码解析: 1、Mapper接口扫描:
a、接口扫描入口位置
入口&＃64;MapperScan
这个注解会&＃64;Import进来一个tk.mapper的扫描器&＃xff08;将MapperScannerRegistrar导入到到Spring容器中&＃xff0c;并将其声明成一个bean&＃xff0c;该类的功能是处理注解MapperScan&＃xff0c;具体过程见后面&＃xff09;
MapperScannerRegistrar实现了spring的ImportBeanDefinitionRegistrar接口, 并实现了registerBeanDefinitions方法。【注&＃xff1a;如下图Spring容器在初始化的时候&＃xff0c;会先扫描基本注解如controller等&＃xff0c;然后扫描第三方jar包中的组件&＃xff0c;扫描完成后再找到实现了ImportBeanDefinitionRegistrar接口的Bean&＃xff0c;并将当前的AnnotationMetadata和BeanDefinitionRegistry作为参数传入&＃xff0c;通过该Bean扫描自定义注解的组件进来】
该bean在实例化的时候,会调用registerBeanDefinitions方法来扫描并导入mapper接口&＃xff0c;接着来看下扫描过程。
b、创建扫描器并利用MapperScan参数初始化该扫描器
该步骤创建一个扫描器, 利用MapperScan参数初始化该扫描器&＃xff0c;各参数意义后面说&＃xff0c;默认为空也没关系。同时还会根据MapperScan参数确定扫描package的范围。
c、注册扫描器filter
之所以把这个单独提出来&＃xff0c;是因为这一步决定了scanner能扫描出哪些mapper&＃xff0c;符合filter条件的就会被扫描出来。
看下registerFilters的具体实现&＃xff1a;
在registerFilters中&＃xff0c;扫描器会添加includeFilter和excludeFilter&＃xff0c;如果扫描出来的类在某一个excludeFilter中&＃xff0c;则放弃该类&＃xff0c;如果扫描出来的类在某一个includeFilter中&＃xff0c;则保存该类到扫描的返回结果中&＃xff0c;excludeFilter要先于includeFilter进行判断。详见&＃xff08;ClassPathScanningCandidateComponentProvider的isCandidateComponent方法&＃xff09;。
下图中annotationClass和markerInterface都是在前面初始化扫描器的时候&＃xff0c;通过MapperScan注解传入的。
d、调用doScan方法扫描mapper
ClassPathMapperScanner这个扫描器继承了ClassPathBeanDefinitionScanner接口&＃xff0c;并重写了doScan方法和isCandidateComponent
doScan&＃xff1a;里面会直接复用父类自带的doScan方法,因为这就是spring扫描包中的bean的方法&＃xff0c;在该方法中&＃xff0c;会先使用上一步调动registerFilters方法注册的过滤器判断扫描出来的类是否符合条件&＃xff08;excludefilter和includefilter判断&＃xff09;&＃xff0c;然后再利用重写后的isCandidateComponent方法进一步判断是否符合条件&＃xff08;默认接口类是不符合Spring扫描条件的&＃xff0c;这里通过重写该方法&＃xff0c;判断扫描出来的类是不是接口且该类metadata中的encloseclass值为null&＃xff0c;是的话就符合扫描条件&＃xff09;&＃xff0c;两个判断都通过&＃xff0c;则认为是扫描出来的mapper接口类。
重写的isCandidateComponent方法
调用父类的doScan后&＃xff0c;会扫描到basePackage指定包下面的mapper接口&＃xff0c;并封装成BeanDefinitionHolder的集合。BeanDefinitionHolder包含了BeanDefinition&＃xff0c;同时包括BeanDefinition的名称和别名
e、使用processBeanDefinitions对扫描出来的mapper的BeanDefinition进行一些修改
processBeanDefinitions主要做了一下几个处理&＃xff1a;
上图处理中&＃xff0c;最重要的就两个&＃xff0c;一是更改BeanClass, 二是设置autowired-mode &＃61; by type,使得SqlSeesionTemplate可以作为MapperFactoryBean的属性注入进来&＃xff08;autowired-mode常见的有三种&＃xff0c; AUTOWIRE_NO、AUTOWIRE_BY_NAME、AUTOWIRE_BY_TYPE&＃xff0c;是基于xml的Spring配置时&＃xff0c;用来定义Bean的注入方式的。利用&＃64;Component等注解创建的Bean默认值都是AUTOWIRE_NO&＃xff0c;表示无需进行属性的注入&＃xff0c;有&＃64;autowire等注解时按注解的方式完成属性注入&＃xff0c;AUTOWIRE_BY_NAME和AUTOWIRE_BY_TYPE分别表示按名称和按类型进行参数的注入。如果该属性为这两个值&＃xff0c;Spring容器在创建Bean的时候会对Bean的属性自动完成注入&＃xff0c;注入时会扫描set方法&＃xff0c;调用set方法并对set方法的参数注入&＃xff0c;从而实现属性的注入。注意&＃xff0c;这里因为是扫描出来的Mapper类的Bean对象且没有&＃64;Component等注解&＃xff0c;所以就通过修改autowired-mode的方式&＃xff0c;通知Spring容器&＃xff0c;对该Bean属性进行注入&＃xff09;。
好了,扫描Mapper的工作到此为止,接下来就是Mapper接口的实例化了。
2、Mapper 接口Bean的实例化:
上面讲到Mapper接口的BeanDefinition的BeanClass被改成了tk.mybatis中的MapperFactoryBean。那么实例化的工作主要会由这个类(实例化出另外一个Bean来替代原始的Mapper接口的Bean)来完成。下面是这个类的依赖关系图。
在图中&＃xff0c;MapperFactoryBean集成的DaoSupport类实现了InitializingBean接口,那么spring在完成属性注入后&＃xff0c;会调DaoSupport的afterPropertiesSet方法。在该afterPropertiesSet中调用了checkDaoConfig方法&＃xff0c;由于MapperFactoryBean重写了checkDaoConfig方法&＃xff0c;所以在Bean属性注入完成后&＃xff0c;会调用MapperFactoryBean的checkDaoConfig方法。
a、关键属性注入
下面来看看MapperFactoryBean的checkDaoConfig方法都做了些什么。但是看之前&＃xff0c;我们先简单了解下该Bean中注入的主要属性&＃xff0c;这些属性在checkDaoConfig方法中用到了&＃xff0c;如果不讲清楚的话&＃xff0c;会很疑惑这些属性是从哪里来的&＃xff0c;了解了才能对tk-mybatis与Spring的集成更加的清楚。
那么被注入的SqlSessionFactory和SqlSessionTemplate是如何被创建的呢&＃xff0c;看下图&＃xff0c;玄机就在mybatis-spring-boot-starter的依赖包中的mybatis-spring-boot-autoconfigure&＃xff1a;
查看该jar包mapper-spring-boot-autoconfigure-2.1.5.jar&＃xff0c;可以发现在META-INF下有个spring.factories文件。
该配置利用Spring的组件扫描机制&＃xff0c;配置了Spring加载jar包后需要扫描的jar包内的配置类。该机制可以参考Spring类SPI机制&＃xff0c;如何将jar包中的类加载到BeanFactory中进行管理。文件内容如下&＃xff1a;
我们看下这个类&＃xff0c;这个类被Spring加载进来后会做很多事情&＃xff1a;
创建SqlSessionFactory的Bean&＃xff1a;
创建SqlSessionTemplate的Bean&＃xff1a;
到这里&＃xff0c;MapperFactoryBean的关键属性的注入讲完了。
b、SqlSessionFactory初始化操作内容
前面讲到MapperFactoryBean自动注入了SqlSessionFactory的Bean&＃xff0c;为了讲清楚MapperFactoryBean在属性注入后执行的checkDaoConfig操作&＃xff0c;我们先了解下SqlSessionFactory初始化的时候都做了什么事情。tkmybatis中SqlSessionFactory的初始化基本就是调用mybatis的初始化过程。简要概括为以下几点&＃xff1a;
-
读取Properties配置文件&＃xff0c;提取mybatis相关配置
-
解析xml文件&＃xff0c;将xml文件mapper节点中的mapper类解析并存放到mapperRegistr中&＃xff0c;作为knowsmapper
-
根据mapper的接口方法&＃xff0c;为每一个方法创建一个对应的mappedStatement&＃xff08;敲黑板&＃xff0c;checkDaoConfig操作主要就是为了调整它&＃xff09;&＃xff0c;创建mappedStatement时会解析mapper中的method方法&＃xff0c;创建对应的SqlSource&＃xff08;根据注解类型判断&＃xff0c;如果是insert等基本注解&＃xff0c;则利用LanguageDriver和注解上的SQL语句来创建SqlSource&＃xff0c;如果是Provider等注解&＃xff0c;tkMybatis就是这一类&＃xff0c;则创建的SqlSource为ProviderSqlSource&＃xff09;
下面从源码里面看下这几部分&＃xff1a;
factory.getObject()方法跟下去&＃xff0c;发现接着会用加载配置的xml文件&＃xff0c;生成Resource列表&＃xff0c;然后遍历处理列表中的Resource
xmlMapperBuilder.parse()方法跟下去&＃xff0c;发现是调用了Mybatis中Configuration的addMapper方法&＃xff08;实现中又是直接调用的MapperRegistry的addMapper方法&＃xff09;&＃xff0c;处理每一个mapper类&＃xff0c;将其添加到mapper注册中心。
再进一步&＃xff0c;看addMapper方法是如何处理mapper类&＃xff0c;注意这里knownMappers.put方法很重要&＃xff0c;knowMappers中保存了根据xml配置获取到的所有的mapper类&＃xff0c;这里在put的时候&＃xff0c;将mapper类转换成了对应的代理类工厂MapperProxyFactory&＃xff08;MapperFactoryBean在完成初始化后&＃xff0c;如果在其他类中需要注入MapperFactoryBean的实例&＃xff0c;会由Spring容器调用它的getObject方法创建并注入进去。在getObject方法里会调用代理工厂类的实例方法&＃xff0c;会利用jdk的动态代理技术为mapper类实例创建对应的代理类实例&＃xff0c;返回给MapperProxyFactory的getObject方法&＃xff0c;随后MapperProxyFactory将该代理类实例作为mapper类的实例&＃xff08;比如UserMapper的实例userMapper&＃xff0c;实际就是Mapper的代理类实例&＃xff09;&＃xff0c;执行sql的时候&＃xff0c;实际SQL调用都是在MapperProxy的invoke方法中进行处理的&＃xff09;
在parse()方法中&＃xff0c;做如下操作&＃xff1a;
parseStatement方法完成MappedStatement创建&＃xff0c;包括根据方法注解创建SqlSource&＃xff0c;然后利用SqlSource创建MappedStatement。
getSqlSource方法会根据mapper方法上的注解类型&＃xff0c;决定返回何种SqlSource。
到这里mapper解析的操作就完成了&＃xff0c;MapperFactoryBean中的configuration保存了每一个mapper方法的mappedStatement以及已知的mapper类。
c、为每个方法对应的MappedStatement更新SqlSource
我们再回到MapperFactoryBean类&＃xff0c;来看看它的checkDaoConfig方法都做了些什么。先把结论说了吧&＃xff0c;checkDaoConfig会根据mapper接口将每个接口方法对应的sqlSource&＃xff0c;由前面说的ProviderSqlSource转换成languageDriver创建的sqlSource&＃xff08;可以理解为tkMybatis根据每个方法的定义&＃xff0c;利用Provider为每个方法在对应的mapper.xml中添加了方法对应的SQL语句&＃xff0c;然后利用修改后的xml创建新的sqlSource&＃xff0c;更新到MappedStatement里面去&＃xff0c;只有更新后的MappedStatement&＃xff0c;才能执行Mybatis的SQL处理。当然实际上是没有直接修改xml文件这一步的&＃xff0c;只是打个比方&＃xff0c;可以看后面的代码实现&＃xff09;。
再继续看processConfiguration方法做了什么操作。
再继续看processMappedStatement对MappedStatement的处理&＃xff0c;该处理中会对MappedStatement中的SqlSource进行替换。
看一下替换前&＃xff0c;MappedStatement中的SqlSource如下图所示&＃xff0c;是个Provider实现类。
执行setSqlSource后&＃xff0c;在下图中可以看见&＃xff0c;MappedStatement中的sqlSource参数已经变成了DynamicSqlSource。
接下来&＃xff0c;我们继续看下setSqlSource到底是怎么改变sqlSource的。
继续看mapperTemplate的setSqlSource方法&＃xff0c;该方法完成了xml形式sql的创建和对应sqlSource的创建。
跟进method.invoke方法&＃xff0c;可以发现&＃xff0c;该方法实际是在mapper接口方法对应的Provider实现类中执行的&＃xff0c;如下图selectByExample方法由ExampleProvider来生成xmlsql。
至此&＃xff0c;tkMybatis就在checkDaoConfig方法中将接口方法对应的MappedStatement中的sqlSource由不能执行的Provider实现类&＃xff0c;转换成了Mybatis中的可执行的sqlSource&＃xff08;根据xmlSql生成&＃xff0c;和mybatis扫描mapper.xml文件中创建的MapperStatement和SqlSource具有同样的功效&＃xff01;&＃xff09;
到目前为止&＃xff0c;经过1、Mapper接口扫描和2、Mapper 接口Bean的实例化就完成了tkMybatis的初始化工作。
3、将Mapper实例注入到依赖该实例的bean中
前面tkMybatis做了两件事情&＃xff0c;一是扫描Mapper接口比如UserMapper&＃xff0c;创建对应的Bean定义&＃xff0c;并将其中的类型修改为MapperFactoryBean&＃xff1b;二是实例化该Bean&＃xff0c;因为类型已经修改为MapperFactoryBean&＃xff0c;就完成MapperFactoryBean的实例化和初始化。
接下来还有关键的一步&＃xff0c;怎么用这个Bean&＃xff0c;我们在写service的时候&＃xff0c;会通过&＃64;autowired注解将Mapper注入到service中&＃xff0c;比如下面的&＃xff1a;
以UsersMapper举个例子&＃xff0c;Spring在注入UsersMapper时&＃xff0c;会调用对应MapperFactoryBean实例的getObject方法&＃xff0c;如下图&＃xff0c;在该方法中&＃xff0c;会创建UsersMapper的的代理类&＃xff0c;进入getmapper这个方法&＃xff0c;会跟到前面第2部分knowMappers部分&＃xff0c;getmapper是从knowMappers获取的Mapper&＃xff0c;该Mapper是一个Mapper接口的代理类MapperProxy&＃xff0c;对UserMapper的方法调用都会有MapperProxy的invoke方法来实现。
这也就解决了“明明是Mapper的接口比如UserMapper&＃xff0c;但是在bean定义中把它的类型改成了MapperFactoryBean&＃xff0c;MapperFactoryBean又没有实现Mapper的接口方法&＃xff0c;那么service中注入的mapper调用方法的时候是如何调用的问题”。
4、实际SQL语句的执行
接着上一部分&＃xff0c;调试下实际执行SQL语句的过程。
其实&＃xff0c;像下图一样&＃xff0c;使用经过注入后的Mapper代理类&＃xff0c;就跟原生Mybatis创建的代理类是一样的&＃xff0c;执行的SQL操作的过程也是一样的。里面的每个接口方法也都有对应的MappedStatement实现。如果对invoke代理的过程感兴趣&＃xff0c;可以调试跟进去看&＃xff0c;看看如何invoke中如何用MappedStatement做具体的SQL处理&＃xff0c;这里就不具体说了。
总结:
和mybatis的关系:
-
在不影响mybatis原有功能的情况下,很好的拓展了mybatis的功能
-
扫描xml的工作依旧由mybatis来完成,再次扫描并注册mapper接口的功能以拓展的方式由tk.mapper复写,扫描后的结果依旧存放在mybatis的Configuration中&＃xff0c;和mybatis自己扫描mapper接口的代码逻辑几乎一致,唯一添加的功能就是,对mybatis的Configuration中的由自己拓展的方法对应的MapperStatement的sqlSource进行更改,以此来提供具体可执行sql
-
后续执行持久化方法,依然是mybatis的代码功能,tk.mapper仅在扫描mapper接口阶段提供了SqlSource
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有