tk.mapper 源码解析

纯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接口已经具有很多方法

image

单表的增删改查都会有对应的api让我们调用,不用在xml中编写对一个方法的sql,如果不需要复杂的持久化操作,设置都可以不用建xml文件。

源码解析:

知识铺垫:

1. mybatis源码
2. @SelectProvider注解的工作原理https://www.jianshu.com/p/7e78ca14ef4a

首先不用多说,自己的Mapper接口凭空多了这么多方法,肯定是与我们继承他的通过Mapper接口有关系。来瞅瞅这个接口。

tk.mybatis.mapper.common.Mapper

image

可以看到他继承了很多其他的Mapper

1、 BaseMapper：提供增删改查的方法

2、ExampleMapper: 提供基于Example（条件）的增删改查的方法

3、RowBoundsMapper ： 提供分页的查询方法
Marker ：没卵用,是空的

下面我们就挑其中的BaseMapper<T>来看看

BaseMapper<T>

BaseMapper又继承了继承增删改查的另外4个Mapper

image

挑一个BaseSelectMapper接口看看

image

他又继承了SelectOneMapper<T>, SelectMapper<T>, SelectAllMapper<T>, SelectCountMapper<T>, SelectByPrimaryKeyMapper<T>, ExistsWithPrimaryKeyMapper<T>这么多接口,

==每一个传承至我们自己的Mapper的方法都对应着一个Mapper接口==

SelectByPrimaryKeyMapper

有一个selectByPrimaryKey的抽象方法,并且有SelectProvider注解

image

SelectProvider这个注解可以指定java类的某个方法来向mybatis提供对应的sql,其工作原理可以看看https://www.jianshu.com/p/7e78ca14ef4a这篇文章

那通用mapper是不是就是这样来实现这些方法的呢？

我们来看看注解中的method方法是不是会返回SQL

image

额,拉了跨,说好的sql呢,这是什么玩意。我当时就懵逼了,这绝对不是可以执行的sql吧,其实这个方法应该没卵用,那么对应的sql究竟是在哪构建的？

基于@SelectProvider注解的工作原理,我们知道mybatis初始化的时候,会在扫描完mapper.xml文件之后,扫描Mapper接口,有这个注解会生成一个MapperStatement对象,里面含有ProviderSqlSource对象,ProviderSqlSource对象有一个属性是指向提供SQL类的方法的。如何不做其他操作,现在这个dynamic方法没法提供实际的作用,是不是在tk.mapper初始化的工程中,改变了ProviderSqlSource指向java方法的对应属性值呢。接下来我们去他的初始化流程去寻找答案。

tk.mapper初始化:

入口@MapperScan

image

这个注解会@Import进来一个tk.mapper的扫描器

image

MapperScannerRegistrar实现了spring的ImportBeanDefinitionRegistrar接口,那么实例化的时候,会调用registerBeanDefinitions方法来导入其他的bean。这里其实就是导入其他Mapper接口

image

说句实话,这个方法的代码和mybatis-spring里面mybatis扫描mapper接口的代码几乎一模一样,干的事也基本一摸一样:

创建一个扫描器,开始并扫描Mapper接口并注册BeanDefinition

image

调用doScan方法

image

这个扫描器肯定继承了ClassPathBeanDefinitionScanner接口（和mybatis-spring里的也一模一样），并重写了doScan方法和isCandidateComponent

doScan：里面会直接复用父类自带的doScan方法,因为这就是spring扫描包中的bean的方法

image

isCandidateComponent:这个方法也必须得复写,这个方法会在扫描到需要注册到spring的beanDefinition后悔进行一次过滤,接口和抽象类是会被过滤的,它复写了这个方法之后,使得Mapper接口被封装成beanDefinition,进而可以创建Bean。

image image

扫描到Mapper接口并封装成BeanDefinition

image

之后会调用processBeanDefinitions对BeanDefinition进行一些修改

image image

这段代码其实也mybatis-spring中的大体一致。

1. 更改BeanClass,

2. 设置autowired-mode = by type,使得SqlSeesionTemplate可以作为MapperFactoryBean的属性注入进来

不同点:

1. BeanClass不是mybatis-spring中的MapperFactoryBean了，然后tk.mapper中的,其他的属性都是用的mybatis里面的。
2. 多了个mapperHelper属性会被注入进来

image

好了,扫描Mapper的工作到此为止,接下来就是Mapper接口的实例化了。

Mapper 接口实例化:

上面讲到Mapper接口的BeanDefinition的BeanClass被改成了tk.mybatis中的MapperFactoryBean。那么实例化的工作主要会由这个类(实例化出另外一个Bean来替代原始的Mapper接口的Bean)来完成。跟mybatis扫描注册Mapper是一样的原理。

MapperFactoryBean

image

最终实现了InitializingBean接口,那么spring会调他的afterPropertiesSet方法

image

调用到自身的checkDaoConfig()

image

方法下面就会用之前注入的mapperHelper来做一些事情

image image

现在有个问题哈,就是mybatis-spring他也在扫描xml文件(因为@MapperScan是tk.mapper的,所以没有扫描接口)

mybatis-spring扫描xml文件:

1. 会把xml文件里的select|update|delete|insert封装成MapperStatement对象放在Configuration对象里,

2. 会根据xml的nameSpace扫描Mapper接口的select|update|delete|insert|SelectProvider注解，封装成MapperStatement对象放在Configuration对象里。

看看mybatis扫描Mapper接口中的@SelectProvider的结果

image

可以看到指定的java类方法就是tk.mapper接口方法的@SelectProvider所指定的,所以接下来这个过程,tk.mapper会改变这个sqlSource的值。

image

获取MapperTemplate对象

image

这里有很多提供了方法的上层Mapper,作为key,value是对应的SelectProvider,SelectProvider都继承了MapperTemplate类。

image

每个SelectProvider内部都会维护一个map,映射支持处理的方法,
我们看看SelectByPrimaryKeyMapper对应的SelectProvider对象里的methodMap维护的是啥,

image

这个方法的逻辑就是遍历registerMapper（map）所有的value值,分别调用supportMethod方法，找到MapperStatement所对应的BaseSeleteProvider。这里返回的就是SelectByPrimaryKeyMapper对应的BaseSeleteProvider

image

然后调他的setSqlSource方法

image image

先从MapperStatement的id取出方法名

image image

其实就是留下 . 后面的就是方法名了

image

根据方法名,从该类内部维护的methodMap中取出method对象

image

现在该类是BeseSelectProvider,方法是selectByPrimaryKey,返回调用它，获取到了带mybatis标签的sql片段

image

之后就是根据sql片段,创建DynamicSqlSource,并替换掉MapperStatement中原来那个无用的ProviderSqlSource

image

反射调用MappedStatement的setSqlSource方法()

image

所以,到此,SelectByPrimaryKeyMapper这个Mapper接口方法已经有了MapperStatement,MapperStatement中的SqlSource也在上诉过程中替换成了一个具有可执行的sql的SqlSource.和mybatis扫描mapper.xml文件中创建的MapperStatement和SqlSource具有同样的功效！

总结:

和mybatis的关系:

1. 在不影响mybatis原有功能的情况下,很好的拓展了mybatis的功能
2. 扫描xml的工作依旧由mybatis来完成,再次扫描并注册mapper接口的功能以拓展的方式由tk.mapper复写,扫描后的结果依旧存放在mybatis的Configuration中，和mybatis自己扫描mapper接口的代码逻辑几乎一致,唯一添加的功能就是,对mybatis的Configuration中的由自己拓展的方法对应的MapperStatement的sqlSource进行更改,以此来提供具体可执行sql
3. 后续执行持久化方法,依然是mybatis的代码功能,tk.mapper仅在扫描mapper接口阶段提供了SqlSource