官网上面讲到：无论是 MyBatis 在预处理语句（PreparedStatement）中设置一个参数时，还是从结果集中取出一个值时， 都会用类型处理器将获取的值以合适的方式转换成 Java 类型。那么为什么会有类型处理器呢？这一点并不难理解，SQL语句事实上可以理解为一门面向数据库的编程语言。所以相对而言都有自己的数据类型。这也就意味着存在数据类型不一至的问题。同时不同的数据库之间数据类型还有一定的差义。类型处理器则就是用于处理数据类型不一至的问题。
笔者看过几个不同的ORM框架都存在着类型处理器的概念。可见类型处理器在ORM框架上实现有多么重要。在官网上面已经列出了20多种的内部类型处理器。笔者建议最好选择性的看。好比如说笔者当前的列子里面用到的一个叫UnknownTypeHandler的类型处理器。
List<Product> products = dao.SelectProducts(30, "a");
<select id="SelectProducts" resultMap="result" >
select * from Products where #{0} > ProductID and ProductName like #{1}
</select>
例子里面并没有指出是什么样子的JAVA类型。所以当然是UnknownTypeHandler类型了。即然这样子我们不烦设置一下他的类型在来看看。我们只要把上面的配置修改一下就可以了。如下红色标记。
<select id="SelectProducts" resultMap="result" >
select * from Products where #{0,javaType=int,jdbcType=NUMERIC} > ProductID and ProductName like #{1,javaType=String,jdbcType=VARCHAR}
</select>
关于#{}的语法问题，相信笔者不用多讲大家都清楚。从上面简单的设置里，我们可以看到源码里面会找到IntegerTypeHandler和StringTypeHandler类型处理器来设置参数。类型处理器都是实现于TypeHandler接口，源码都存放在org.apache.ibatis.type的命名空间下。TypeHandler接口的源码也很简单。我们可以看到setParameter方法。顾名思义他就是用于设置参数。其他的方法都是用于处理回返的结果。如下。
public interface TypeHandler<T> {
void setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException;
T getResult(ResultSet rs, String columnName) throws SQLException;
T getResult(ResultSet rs, int columnIndex) throws SQLException;
T getResult(CallableStatement cs, int columnIndex) throws SQLException;
}
想要了解源码，就要找一个合适的入切类——笔者选择IntegerTypeHandler类。IntegerTypeHandler类并没有直接的实现了TypeHandler接口。而是继承了BaseTypeHandler类。正如上面所讲的，BaseTypeHandler类的setParameter方法我们必须了解一下。如下
1 public void setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException {
2 if (parameter == null) {
3 if (jdbcType == null) {
4 throw new TypeException("JDBC requires that the JdbcType must be specified for all nullable parameters.");
5 }
6 try {
7 ps.setNull(i, jdbcType.TYPE_CODE);
8 } catch (SQLException e) {
9 throw new TypeException("Error setting null for parameter #" + i + " with JdbcType " + jdbcType + " . " +
10 "Try setting a different JdbcType for this parameter or a different jdbcTypeForNull configuration property. " +
11 "Cause: " + e, e);
12 }
13 } else {
14 try {
15 setNonNullParameter(ps, i, parameter, jdbcType);
16 } catch (Exception e) {
17 throw new TypeException("Error setting non null for parameter #" + i + " with JdbcType " + jdbcType + " . " +
18 "Try setting a different JdbcType for this parameter or a different configuration property. " +
19 "Cause: " + e, e);
20 }
21 }
22 }
源码的意思很简单——把参数分为非空值和空值来分别设置。空值的设置方法是JDBC内部自己的。而非空值的方法是mybatis自己封装的。所以我们可以看到setNonNullParameter方法是一个抽象方法。看样子我们可以猜测的出来——真正的实现是放在子类的setNonNullParameter方法里面。
public abstract void setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException;
来看一下IntegerTypeHandler类的setNonNullParameter方法。
public void setNonNullParameter(PreparedStatement ps, int i, Integer parameter, JdbcType jdbcType)
throws SQLException {
ps.setInt(i, parameter);
}
事实上笔者认为IntegerTypeHandler类没有什么可看的。但是UnknownTypeHandler类的处理却得我们去研究。我们可以先想一下——不知道类型的情况下，如何知道需要的类型处理器。
public void setNonNullParameter(PreparedStatement ps, int i, Object parameter, JdbcType jdbcType)
throws SQLException {
TypeHandler handler = resolveTypeHandler(parameter, jdbcType);
handler.setParameter(ps, i, parameter, jdbcType);
}
不难看出他又根据参数值和JDBC数据类型来判断获得相应的类型处理器。然后在进行参数设值。所以我们的目标移向resolveTypeHandler方法。
1 private TypeHandler<? extends Object> resolveTypeHandler(Object parameter, JdbcType jdbcType) {
2 TypeHandler<? extends Object> handler;
3 if (parameter == null) {
4 handler = OBJECT_TYPE_HANDLER;
5 } else {
6 handler = typeHandlerRegistry.getTypeHandler(parameter.getClass(), jdbcType);
7 // check if handler is null (issue #270)
8 if (handler == null || handler instanceof UnknownTypeHandler) {
9 handler = OBJECT_TYPE_HANDLER;
10 }
11 }
12 return handler;
13 }
源码的意思是判断传入的参数值是不是为空的，空则调用ObjectTypeHandler类型处器。如果不为空，根据参数传入的类型和当前JDBC数据类型来获得相应的类型处理器。如果还是找不到或是还是UnknownTypeHandler类，则调用ObjectTypeHandler类型处器。UnknownTypeHandler类实际没有设置参数值的功能。而是由其他的类型处理器来实现。
好了，到了这里面对于类型处理器，相信大家都有了一定的理解。但是这里还有一个问题值得我们去研究一下——类型处理器是什么时候创建的。想要了解他的来源就必须回头去看一下DefaultParameterHandler类的setParameters方法。也就是上一章的结尾处相同的代码。
public void setParameters(PreparedStatement ps) {
ErrorContext.instance().activity("setting parameters").object(mappedStatement.getParameterMap().getId());
List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
if (parameterMappings != null) {
for (int i = 0; i < parameterMappings.size(); i++) {
ParameterMapping parameterMapping = parameterMappings.get(i);
if (parameterMapping.getMode() != ParameterMode.OUT) {
Object value;
String propertyName = parameterMapping.getProperty();
if (boundSql.hasAdditionalParameter(propertyName)) { // issue #448 ask first for additional params
value = boundSql.getAdditionalParameter(propertyName);
} else if (parameterObject == null) {
value = null;
} else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
value = parameterObject;
} else {
MetaObject metaObject = configuration.newMetaObject(parameterObject);
value = metaObject.getValue(propertyName);
}
TypeHandler typeHandler = parameterMapping.getTypeHandler();
JdbcType jdbcType = parameterMapping.getJdbcType();
if (value == null && jdbcType == null) {
jdbcType = configuration.getJdbcTypeForNull();
}
try {
typeHandler.setParameter(ps, i + 1, value, jdbcType);
} catch (TypeException e) {
throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);
} catch (SQLException e) {
throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);
}
}
}
}
BoundSql类上一章笔者也有讲到。他是用于存放sql语句信息。为什么这里要提到他呢？相信从源码里面我们可以看到类型处理器是通过ParameterMapping类来获得的。而ParameterMapping类又是通过 BoundSql类获得。所以就不得不去了解一下BoundSql类是如何获得ParameterMapping类的。
关于如何BoundSql类是如何获得ParameterMapping类的。事实这一块跟XMLMapperBuilder类有关系。XMLMapperBuilder类就是用于加载Mapper文件的。而他的configurationElement方法。正是我们现在需要了解的。如下
private void configurationElement(XNode context) {
try {
String namespace = context.getStringAttribute("namespace");
if (namespace == null || namespace.equals("")) {
throw new BuilderException("Mapper's namespace cannot be empty");
}
builderAssistant.setCurrentNamespace(namespace);
cacheRefElement(context.evalNode("cache-ref"));
cacheElement(context.evalNode("cache"));
parameterMapElement(context.evalNodes("/mapper/parameterMap"));
resultMapElements(context.evalNodes("/mapper/resultMap"));
sqlElement(context.evalNodes("/mapper/sql"));
buildStatementFromContext(context.evalNodes("select|insert|update|delete"));
} catch (Exception e) {
throw new BuilderException("Error parsing Mapper XML. Cause: " + e, e);
}
}
最后面的buildStatementFromContext方法是了解如何获得ParameterMapping类的开头。这句代码中已经很明显的看出他是用于加载select,insert等节点信息。当我们继续跟进去的话，最终会看到一个了parseStatementNode方法。这一个过程读者们自行查看。
1 processSelectKeyNodes(id, parameterTypeClass, langDriver);
2
3 // Parse the SQL (pre: <selectKey> and <include> were parsed and removed)
4 SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
5 String resultSets = context.getStringAttribute("resultSets");
6 String keyProperty = context.getStringAttribute("keyProperty");
7 String keyColumn = context.getStringAttribute("keyColumn");
笔者只是贴出一部分的代码。红色标记的内容是我们所要关注的重点。（其外parseStatementNode方法还是了解如何创建MappedStatement类的入口类。）笔者为什么要提到SqlSource接口呢？我们都知道在mybatis框架里面的sql语句决不可能只有sql语句。还会出现if之类的语法。那么这种sql语句，mybatis框架叫他为动态 SQL。而BoundSql类就是通过SqlSource接口所继承的类获得。
mybatis对sql语句定义为三种半。为什么是三种半呢？因为还有一个可能正在研发中。每一种在源码中都有相关的类。
1.DynamicSqlSource类用于动态SQL。
2.StaticSqlSource类用于静态SQL。
3.ProviderSqlSource类用于脚本语言。
4.VelocitySqlSource类用于XXX。还是读者们自己去看吧。
SqlSource接口的源码才是笔者为什么要讲SqlSource接口的最好证明。如下
public interface SqlSource {
BoundSql getBoundSql(Object parameterObject);
}
我们搞清楚了BoundSql类是哪里来了之后。我们在去了解如何获得ParameterMapping类就变得简单多了。这里笔者就不把全部的过程拿出来讲了。就直接把获得ParameterMapping类的始点提出来——SqlSourceBuilder类的parse方法里面。
public SqlSource parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters) {
ParameterMappingTokenHandler handler = new ParameterMappingTokenHandler(configuration, parameterType, additionalParameters);
GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
String sql = parser.parse(originalSql);
return new StaticSqlSource(configuration, sql, handler.getParameterMappings());
}
ParameterMappingTokenHandler类就是用于解析ParameterMapping类的。具体如何去解析不用笔者在动手吧。在建新ParameterMapping类的时候，他的内部resolveTypeHandler方法会被调用。而这个时候我们的类型处理器正式出现了。
private void resolveTypeHandler() {
if (parameterMapping.typeHandler == null && parameterMapping.javaType != null) {
Configuration configuration = parameterMapping.configuration;
TypeHandlerRegistry typeHandlerRegistry = configuration.getTypeHandlerRegistry();
parameterMapping.typeHandler = typeHandlerRegistry.getTypeHandler(parameterMapping.javaType, parameterMapping.jdbcType);
}
}
类型处理器相关的内容。到了这里可以说是结束了。我们知道了他的来源，也知道了他的去处。事实如果我们认真点去了解正个过程。你们会发现这个过程用于很buidler设计模式。同时mybatis框架把mapper文件的信息分为mapper根处理、四节点处理、脚本处理、SQL语句处理。
1.Mapper根处理对应的XMLMapperBuilder类。
2.四节点处理对应的XMLStatementBuilder类。即是select节点，update节点，insert节点，delect节点。
3.脚本处理对应的XMLScriptBuilder类。
4.SQL语句处理对应的SqlSourceBuilder类。
当然这也是笔者自己的看法而以。不一定对。你们可以自己去了解。