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