1 缘起
最近在测试MyBatis进行CURD时,
发现,MyBatis数据绑定两种形式,
通过对象绑定和@Param绑定,
说起来也怪,有时候,只想解决一个问题,
可是,牵扯出来一些列问题。
本想只研究下@Param是如何绑定数据,
可是在调试过程中,牵扯出了一系列有用的知识点,
于是,梳理,形成笔记。
声明:
MyBatis版本:3.5.3
<!-- https://mvnrepository.com/artifact/org.mybatis/mybatis -->
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.5.3</version>
</dependency>
2 流程
先上结果,
MyBatis中如何逐步使用JDK代理:InvocationHandler,Proxy.newProxyInstance完成数据CURD的?
整体流程如下图所示。
从DefaultSqlSession#getMapper开始,处理映射,
从MapperProxyFactory#newInstance开始进入代理,
从MapperProxy#invoke执行代理逻辑,
在ParamNameResolver#ParamNameResolver中处理@Param注解,
最终的CURD在MapperMethod#execute中实现。
3 实践分析
通过调试,
逐步探寻MyBatis是如何使用JDK代理、处理@Param,
完成CURD操作的,
具体的分析过程如下。
3.1 DAO
数据库操作接口,
这里测试查询,并使用@Param绑定数据。
package com.monkey.java_study.database.dao;
import com.monkey.java_study.database.dto.UserCreateDTO;
import com.monkey.java_study.database.dto.UserEditDTO;
import com.monkey.java_study.database.dto.UserOutputDTO;
import org.apache.ibatis.annotations.Param;
import java.util.List;
/**
* 数据库操作.
*
* @author xindaqi
* @date 2021-05-14 16:08
*/
public interface UserDAO {
/**
* 根据id查询数据.
*
* @param id 用户id
* @return 用户数据
*/
UserOutputDTO queryUserById(@Param("id") long id);
}
3.2 Mapper
数据库操作实现,映射上面的接口,这里只实现了查询,并使用了#作为取参标识,防止SQL注入。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.monkey.java_study.database.dao.UserDAO">
<select id="queryUserById" resultType="com.monkey.java_study.database.dto.UserOutputDTO">
SELECT
user_id, username, created_time
FROM
tb_user
WHERE
id=#{id}
</select>
</mapper>
3.3 调试
测试样例如下图所示。
测试数据查询。
3.3.1 DefaultSqlSession#getMapper
入口,获取代理对象DAO,
为后面的代理执行做准备。
使用DefaultSqlSession。
位置:org.apache.ibatis.session.defaults.DefaultSqlSession#getMapper
源码如下图所示。
3.3.2 Configuration#getMapper
通过MapperRegistry获取DAO。
位置:org.apache.ibatis.session.Configuration#getMapper
源码如下图所示。
3.3.3 MapperRegistry#getMapper
通过该MapperProxyFactory获取DAO。
位置:org.apache.ibatis.binding.MapperRegistry#getMapper
源码如下图所示。
3.3.4 MapperProxyFactory#newInstance
通过MapperProxy实例化代理对象,
因为MapperProxy实现了InvocationHandler,
接下来要调用Proxy.newProxyInstance才能执行invoke。
位置:org.apache.ibatis.binding.MapperProxyFactory#newInstance(org.apache.ibatis.session.SqlSession)
源码如下图所示。
3.3.5 MapperProxyFactory#newInstance
由上面可知,通过newInstance进入Proxy.newProxyInstance,
这才是熟悉的JDK代理。
这里才最终成功获取需要的DAO,为后续的invoke做准备。
位置:org.apache.ibatis.binding.MapperProxyFactory#newInstance(org.apache.ibatis.binding.MapperProxy)
源码如下图所示。
3.3.6 CURD逻辑
获取代理DAO后,
下一步指定CURD即可直接进入invoke逻辑。
这里是查询:UserOutputDTO userOutputDTO = userDAO.queryUserById(id);
测试样例代码如下图所示。
3.3.7 执行invoke:MapperProxy#invoke
正式进入代理逻辑,执行invoke,
这里会有直接处理逻辑,见后文。
位置:org.apache.ibatis.binding.MapperProxy#invoke
源码如下图所示。
3.3.8 MapperProxy#cachedMapperMethod
通过cachedMapperMethod实例化MapperMethod,
执行方法。
位置:org.apache.ibatis.binding.MapperProxy#cachedMapperMethod
源码如下图所示。
3.3.9 MapperMethod#MapperMethod
实例化MethodSignature,
配置相应的反射方法,
处理@Param注解。
位置:org.apache.ibatis.binding.MapperMethod#MapperMethod
源码如下图所示。
3.3.10 MethodSignature#MethodSignature
这里实例化ParamNameResolver,
处理@Param注解,具体逻辑见后文。
位置:org.apache.ibatis.binding.MapperMethod.MethodSignature#MethodSignature
源码如下图所示。
3.3.11 处理@Param
具体的@Param处理逻辑如下图所示,
通过method.getParameterAnnotations获取相关注解,
匹配Param,并处理。
位置:org.apache.ibatis.reflection.ParamNameResolver#ParamNameResolver
源码如下图所示。
3.3.12 MapperMethod#execute
invoke中的最后一步,即执行具体的SQL,完成CURD,
具体的逻辑见后文。
如下图所示。
最终执行中通过switch,匹配对应的CURD,
源码如下图所示,
由图可知,INSERT、UPDATE、DELETE、SELECT,
执行,并返回对应的结果:rowCountResult(…)
位置:org.apache.ibatis.binding.MapperMethod#execute
到这里MyBatis通过JDK代理完成了CURD操作。
4 小结
(1)MyBatis通过JDK代理完成CURD操作;
(2)通过反射处理注解,
其中,
(2.1)@Param在ParamNameResolver#ParamNameResolver中处理;
(2.2)@Select、@Insert、@Upate和@Delete注解通过MapperAnnotationBuilder#chooseAnnotationType处理;
(3)通过org.apache.ibatis.builder.xml.XMLMapperBuilder加载Xml配置。