《Mybatis 手撸专栏》第10章:使用策略模式,调用参数处理器
作者:小傅哥
博客:https://bugstack.cn
沉淀、分享、成长,让自己和他人都能有所收获!??
一、前言
你这代码写的,咋这么轴呢!
说到轴,让我想起初中上学时老师说的话:“你那脑瓜子,咋跟手焖子似的!” 东北话手焖子就是那种冬天戴的大棉手套,棉手套里的棉花都被压的又沉又硬的了,所以来比喻脑瓜子笨。
而写轴代码的大部分都是刚毕业没多久,或者刚开始工作的码农,毕竟经验不足经历不多,写出一些不太好维护的代码也情有可原。而那些绝对多数锻炼出来的老码农,其实代码的稳定程度、设计经验、缜密逻辑,都是相对来说要好很多的。当然一部分老码农,只是老了而已,代码还是那个代码!
所以企业招聘些年轻人,需要年轻的思想。但没必要嚯嚯只是头发没多少的老码农,否则谁来给你平稳落地你那些天马行空的想法呢!难道体验、稳定、流畅,不应该是更值得追求的,非得喜欢全是愣头青似的代码,写出几百个bug,造成大量资损和客诉,让老板觉得很爽?
二、目标
上一章节,小傅哥带着大家细化的 XML 语句构建器,解耦在解析 XML 中的所需要处理的 Mapper 信息,包括;SQL、入参、出参、类型,并对这些信息进行记录到 ParameterMapping 参数映射处理类中。那么这个一章节我们将结合这部分参数的提取,对执行的 SQL 进行参数的自动化设置,而不是像我们之前那样把参数写成固定的,如图 10-1 所示
- 在流程上,通过 DefaultSqlSession#selectOne 方法调用执行器,并通过预处理语句处理器 PreparedStatementHandler 执行参数设置和结果查询。
- 那么这个流程中我们所处理的参数信息,也就是每个 SQL 执行时,那些
?号
需要被替换的地方,目前是通过硬编码的方式进行处理的。而这就是本章节需要解决的问题,如果只是硬编码完成参数设置,那么对于所有那些不同类型的参数就没法进行操作了。 - 所以本章节需要结合结合上一章节所完成的语句构建器对 SQL 参数信息的拆解,本章将会按照这些参数的解析,处理这里硬编码为自动化类型设置。针对不同类型的参数设置,这部分使用了什么设计模式呢?
三、设计
这里可以思考??下,参数的处理也就是通常我们使用 JDBC 直接操作数据库时,所使用 ps.setXxx(i, parameter);
设置的各类参数。那么在自动化解析 XML 中 SQL 拆分出所有的参数类型后,则应该根据不同的参数进行不同的类型设置,也就;Long 调用 ps.setLong
、String 调用 ps.setString
所以这里需要使用策略模式,在解析 SQL 时按照不同的执行策略,封装进去类型处理器(也就是是实现 TypeHandler
- 其实关于参数的处理,因为有很多的类型(
Long\String\Object\...
),所以这里最重要的体现则是策略模式的使用。 - 这里包括了构建参数时根据类型,选择对应的策略类型处理器,填充到参数映射集合中。另外一方面是参数的使用,也就是在执行 DefaultSqlSession#selectOne 的链路中,包括了参数的设置,按照参数的不同类型,获取出对应的处理器,以及入参值。注意:由于入参值可能是一个对象中的属性,所以这里我们用到了前面章节实现的反射类工具 MetaObject 进行值的获取,避免由于动态的对象,没法硬编码获取属性值。
四、实现
1. 工程结构
mybatis-step-09
└── src
├── main
│ └── java
│ └── cn.bugstack.mybatis
│ ├── binding
│ │ ├── MapperMethod.java
│ │ ├── MapperProxy.java
│ │ ├── MapperProxyFactory.java
│ │ └── MapperRegistry.java
│ ├── builder
│ │ ├── xml
│ │ │ ├── XMLConfigBuilder.java
│ │ │ ├── XMLMapperBuilder.java
│ │ │ └── XMLStatementBuilder.java
│ │ ├── BaseBuilder.java
│ │ ├── ParameterExpression.java
│ │ ├── SqlSourceBuilder.java
│ │ └── StaticSqlSource.java
│ ├── datasource
│ ├── executor
│ │ ├── resultset
│ │ │ └── ParameterHandler.java
│ │ ├── resultset
│ │ │ ├── DefaultResultSetHandler.java
│ │ │ └── ResultSetHandler.java
│ │ ├── statement
│ │ │ ├── BaseStatementHandler.java
│ │ │ ├── PreparedStatementHandler.java
│ │ │ ├── SimpleStatementHandler.java
│ │ │ └── StatementHandler.java
│ │ ├── BaseExecutor.java
│ │ ├── Executor.java
│ │ └── SimpleExecutor.java
│ ├── io
│ ├── mapping
│ │ ├── BoundSql.java
│ │ ├── Environment.java
│ │ ├── MappedStatement.java
│ │ ├── ParameterMapping.java
│ │ ├── SqlCommandType.java
│ │ └── SqlSource.java
│ ├── parsing
│ ├── reflection
│ ├── scripting
│ │ ├── defaults
│ │ │ └── DefaultParameterHandler.java
│ │ ├── xmltags
│ │ │ ├── DynamicContext.java
│ │ │ ├── MixedSqlNode.java
│ │ │ ├── SqlNode.java
│ │ │ ├── StaticTextSqlNode.java
│ │ │ ├── XMLLanguageDriver.java
│ │ │ └── XMLScriptBuilder.java
│ │ ├── LanguageDriver.java
│ │ └── LanguageDriverRegistry.java
│ ├── session
│ │ ├── defaults
│ │ │ ├── DefaultSqlSession.java
│ │ │ └── DefaultSqlSessionFactory.java
│ │ ├── Configuration.java
│ │ ├── ResultHandler.java
│ │ ├── SqlSession.java
│ │ ├── SqlSessionFactory.java
│ │ ├── SqlSessionFactoryBuilder.java
│ │ └── TransactionIsolationLevel.java
│ ├── transaction
│ └── type
│ ├── BaseTypeHandler.java
│ ├── JdbcType.java
│ ├── LongTypeHandler.java
│ ├── StringTypeHandler.java
│ ├── TypeAliasRegistry.java
│ ├── TypeHandler.java
│ └── TypeHandlerRegistry.java
└── test
├── java
│ └── cn.bugstack.mybatis.test.dao
│ ├── dao
│ │ └── IUserDao.java
│ ├── po
│ │ └── User.java
│ └── ApiTest.java
└── resources
├── mapper
│ └──User_Mapper.xml
└── mybatis-config-datasource.xml
工程源码:https://github.com/fuzhengwei/small-mybatis
使用策略模式,处理参数处理器核心类关系,如图 10-3 所示
核心处理主要分为三块;类型处理、参数设置、参数使用;
- 以定义 TypeHandler 类型处理器策略接口,实现不同的处理策略,包括;Long、String、Integer 等。这里我们先只实现2种类型,读者在学习过程中,可以按照这个结构来添加其他类型。
- 类型策略处理器实现完成后,需要注册到处理器注册机中,后续其他模块参数的设置还是使用都是从 Configuration 中获取到 TypeHandlerRegistry 进行使用。
- 那么有了这样的策略处理器以后,在进行操作解析 SQL 的时候,就可以按照不同的类型把对应的策略处理器设置到 BoundSql#parameterMappings 参数里,后续使用也是从这里进行获取。
2. 入参数校准
这里我们要先解决一个小问题,不知道读者在我们所实现的源码中,是否注意到这样一个参数的传递,如图 10-4
- 这里的参数传递后,需要获取第0个参数,而且是硬编码固定的。这是为什么呢?这个第0个参数是哪来的,我们接口里面调用的方法,参数不是一个吗?就像:
User queryUserInfoById(Long id);
- 其实这个参数来自于映射器代理类 MapperProxy#invoke 中,因为 invoke 反射调用的方法,入参中是 Object[] args,所以这个参数被传递到后续的参数设置中。而我们的 DAO 测试类是一个已知的固定参数,所以后面硬编码了获取了第0个参数。
- JDK 反射调用方法操作固定方法入参
- 那么结合这样的问题,我们则需要根据方法的信息,给方法做签名操作,以便于转换入参信息为方法的信息。比如数组转换为对应的对象。
源码详见:cn.bugstack.mybatis.binding.MapperMethod
public class MapperMethod {
public Object execute(SqlSession sqlSession, Object[] args) {
Object result = null;
switch (command.getType()) {
case SELECT:
Object param = method.convertArgsToSqlCommandParam(args);
result = sqlSession.selectOne(command.getName(), param);
break;
default:
throw new RuntimeException("Unknown execution method for: " + command.getName());
}
return result;
}
/**
* 方法签名
*/
public static class MethodSignature {
public Object convertArgsToSqlCommandParam(Object[] args) {
final int paramCount = params.size();
if (args == null || paramCount == 0) {
// 如果没参数
return null;
} else if (paramCount == 1) {
return args[params.keySet().iterator().next().intValue()];
} else {
// 否则,返回一个ParamMap,修改参数名,参数名就是其位置
final Map param = new ParamMap