回顾
上篇，我们分析了TypeHandler的注册过程，分析了12个register方法之间盘根错节的关系，最终得出注册过程就是构建三个Map的过程。在这个过程中，为使文章脉络清晰，跳过了@MappedTypes、@MappedJdbcTypes注解相关的内容。跳过并非不重要，相反，这俩注解在自定义TypeHandler的过程中扮演着相当重要的角色，因此，为使知识点完整，本文将分析@MappedTypes、@MappedJdbcTypes注解的使用
正文
@MappedTypes: 用于指定TypeHandler能处理的JavaType
上篇中，我们提到过TypeReference，自定义的TypeHandler一般会间接继承该类，Mybatis通过该类从泛型中提取JavaType。除此之外，还可以通过@MappedTypes注解直接标明JavaType，而且注解的优先级高于泛型提取方式。也即是说，假若使用了@MappedTypes注解，会忽视泛型中的JavaType
@MappedJdbcTypes: 用于限定TypeHandler能处理的JdbcType
注意二者措词稍有不同，前者是指定，而后者是限定。前者突出的是：在泛型提取方式的基础上，允许通过某种方式强行指定能处理的JavaType，而后者突出的是：在原来不加限制的JdbcType上，通过某种方式限定仅允许处理某种JdbcType。
举个例子，自定义的TypeHandler未指定@MappedJdbcTypes，能够处理多种类型，如VARCHAR、CHAR等，一旦限定为@MappedJdbcTypes(JdbcType.VARCHAR)，就只能处理VARCHAR。这样会导致一个奇怪问题：在Mapper.xml使用resultMap定义结果集映射，属性未指定jdbcType，Mybatis就按照javaType=[TheJavaType], jdbcType=null去TypeHandlerRegistry中找，由于限定了自定义TypeHandler的JdbcType为VARCHAR，Map里找不到，因此查找失败。懒惰是程序员的天性，倘若是手写的Mapper.xml，很多开发人员并不会主动指定JdbcType，程序就要报错了。
为了解决这个问题，@MappedJdbcTypes有一个属性includeNullJdbcType用于指定是否将null作为JdbcType进行注册，默认值是false。我们可以手动指定指为true，如此，Mybatis按照javaType=[TheJavaType], jdbcType=null去TypeHandlerRegistry中就能找到我们自定义的TypeHandler
更进一步地，为了让MyBatis用起来更方便一些，从MyBatis 3.4.0开始，即便未指定includeNullJdbcType=true，对于那些只存在一个TypeHandler的JavaType，TypeHandler也会生效。再也不用担心使用@MappedJdbcTypes限定JdbcType之后，忘记配置includeNullJdbcType=true而导致程序启动失败。(Since Mybatis 3.4.0 however, if a single TypeHandler is registered to handle a Java type, it will be used by default in ResultMaps using this Java type (i.e. even without includeNullJdbcType=true))
案例
为了方便，仍然使用上篇的例子
上篇中，定义了抽象基类AbstractObjectTypeHandler，以及能处理JavaType=Bar的具体实现类BarTypeHandler，文中还提到，如果要处理别的JavaType，只要继承AbstractObjectTypeHandler，并在泛型实现中写上JavaType即可。虽然这已经是一种很优雅的扩展方式(开闭原则)，但是如果存在另一种方式，能够减少类的膨胀，让我们在使用之余，多一种考量方式，岂非更好？请看下述代码：
@MappedTypes(Bar.class)
public class GenericTypeHandler<T> extends BaseTypeHandler<T> {
private Class<T> type;
public GenericTypeHandler(Class<T> type) {
if (type == null) throw new IllegalArgumentException("Type argument cannot be null");
this.type = type;
}
@Override
public void setNonNullParameter(PreparedStatement ps, int i, Object parameter,
JdbcType jdbcType) throws SQLException {
ps.setString(i, JsonUtil.toJson(parameter));
}
@Override
public T getNullableResult(ResultSet rs, String columnName)
throws SQLException {
String data = rs.getString(columnName);
return StringUtils.isBlank(data) ? null : JsonUtil.fromJson(data, type);
}
@Override
public T getNullableResult(ResultSet rs, int columnIndex) throws SQLException {
String data = rs.getString(columnIndex);
return StringUtils.isBlank(data) ? null : JsonUtil.fromJson(data, type);
}
@Override
public T getNullableResult(CallableStatement cs, int columnIndex)
throws SQLException {
String data = cs.getString(columnIndex);
return StringUtils.isBlank(data) ? null : JsonUtil.fromJson(data, type);
}
}
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface MappedTypes {
Class<?>[] value();
}
我们定义了一个通用的类型处理器，没有指定泛型具体实现，而是通过在类上使用@MappedTypes来指定能处理的JavaType，我们指定了Bar.class，说明该类型处理器能够处理Bar。看一下@MappedTypes的定义，发现value是个class类型的数组，也即是说，除了Bar，还可以继续在上面追加需要处理的JavaType
如此一来，只需要定义一个类型处理器，通过指定@MappedTypes的方式，就能处理多个JavaType，有效地抑制了类膨胀
如果说@MappedTypes能抑制类膨胀，可以忽视泛型提取，强制指定JavaType方面有作用，那@MappedJdbcTypes就比较鸡肋了。它的出现，是为了限制能支持的JdbcType，但在很多场景中，并不需要限制，只在有限的场景，如同一JavaType在不同的表有不同的字段类型，对应有多个TypeHandler的转换逻辑，这时候需要通过@MappedJdbcTypes分别指定JdbcType
原理分析
上篇分析12个register方法可以得出如下结论：
- 跟
@MappedTypes注解相关的有2个单参的register方法 - 跟
@MappedJdbcTypes注解相关的有1个双参的register方法
相关源码如下：
public void register(Class<?> typeHandlerClass) {
// 单参，与`@MappedTypes`相关
boolean mappedTypeFound = false;
MappedTypes mappedTypes = typeHandlerClass.getAnnotation(MappedTypes.class);
if (mappedTypes != null) {
for (Class<?> javaTypeClass : mappedTypes.value()) {
register(javaTypeClass, typeHandlerClass);
mappedTypeFound = true;
}
}
if (!mappedTypeFound) {
register(getInstance(null, typeHandlerClass));
}
}
根据传进来的typeHandlerClass获取定义在其上的注解MappedTypes，并提取注解指定的JavaType集合，循环调用register(javaTypeClass, typeHandlerClass)进行注册，此处源码可以回应上面结论：
如此一来，只需要定义一个类型处理器，通过指定
@MappedTypes的方式，就能处理多个JavaType
public <T> void register(TypeHandler<T> typeHandler) {
// 单参，与`@MappedTypes`相关
boolean mappedTypeFound = false;
MappedTypes mappedTypes = typeHandler.getClass().getAnnotation(MappedTypes.class);
if (mappedTypes != null) {
for (Class<?> handledType : mappedTypes.value()) {
register(handledType, typeHandler);
mappedTypeFound = true;
}
}
// 下半部分在上篇文章已分析，不再赘述
// @since 3.1.0 - try to auto-discover the mapped type
if (!mappedTypeFound && typeHandler instanceof TypeReference) {
try {
TypeReference<T> typeReference = (TypeReference<T>) typeHandler;
register(typeReference.getRawType(), typeHandler);
mappedTypeFound = true;
} catch (Throwable t) {
// maybe users define the TypeReference with a different type and are not assignable, so just ignore it
}
}
if (!mappedTypeFound) {
register((Class<T>) null, typeHandler);
}
}
此处与前面的方法很像，前面的单参是个typeHandlerClass，而此处是个typeHandler实例，因此多了一步，先获取typeHandlerClass，再获取注解在其上的@MappedTypes，后面的步骤也是一样的，都是为了注册通过注解指定的JavaType
private <T> void register(Type javaType, TypeHandler<? extends T> typeHandler) {
// 双参，与`@MappedJdbcTypes`相关
MappedJdbcTypes mappedJdbcTypes = typeHandler.getClass().getAnnotation(MappedJdbcTypes.class);
if (mappedJdbcTypes != null) {
for (JdbcType handledJdbcType : mappedJdbcTypes.value()) {
register(javaType, handledJdbcType, typeHandler);
}
if (mappedJdbcTypes.includeNullJdbcType()) {
register(javaType, null, typeHandler);
}
} else {
register(javaType, null, typeHandler);
}
}
通过typeHandler实例获取其class，并拿到注解在类上的@MappedJdbcTypes，并获取限定的JdbcType集合，调用register(javaType, handledJdbcType, typeHandler)进行注册。如果注解指定了includeNullJdbcType=true，会将JdbcType=null进行注册(register(javaType, null, typeHandler))，也就应证了上文：
@MappedJdbcTypes有一个属性includeNullJdbcType用于指定是否将null作为JdbcType进行注册，默认值是false
关于@MappedTypes、@MappedJdbcTypes 注解相关的注册过程，已经分析完毕。可以看到，注解是一个加强功能，它与注册主流程并不强相关，不存在强依赖关系，只是在TypeHandler注册过程给开了一个口子，允许强行指定的JavaType或者限定JdbcType。至于注册后的使用，与上篇阐述的没有任何区别，因此不再赘述
至此，还剩一个论点未曾分析到：
Since Mybatis 3.4.0 however, if a single TypeHandler is registered to handle a Java type, it will be used by default in ResultMaps using this Java type (i.e. even without includeNullJdbcType=true)
我们来看一下，在源码上是如何体现的，参考：org.apache.ibatis.type.TypeHandlerRegistry#getTypeHandler(java.lang.reflect.Type, org.apache.ibatis.type.JdbcType)
private <T> TypeHandler<T> getTypeHandler(Type type, JdbcType jdbcType) {
if (ParamMap.class.equals(type)) {
return null;
}
Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = getJdbcHandlerMap(type);
TypeHandler<?> handler = null;
if (jdbcHandlerMap != null) {
handler = jdbcHandlerMap.get(jdbcType);
if (handler == null) {
handler = jdbcHandlerMap.get(null);
}
if (handler == null) {
// #591
handler = pickSoleHandler(jdbcHandlerMap);
}
}
// type drives generics here
return (TypeHandler<T>) handler;
}
private TypeHandler<?> pickSoleHandler(Map<JdbcType, TypeHandler<?>> jdbcHandlerMap) {
TypeHandler<?> soleHandler = null;
for (TypeHandler<?> handler : jdbcHandlerMap.values()) {
if (soleHandler == null) {
soleHandler = handler;
} else if (!handler.getClass().equals(soleHandler.getClass())) {
// More than one type handlers registered.
return null;
}
}
return soleHandler;
}
获取typeHandler有可能经历三次：
- 根据指定的
JdbcType从jdbcHandlerMap中获取 - 若获取失败，用
JdbcType=null从jdbcHandlerMap中获取 - 还获取失败，判断
jdbcHandlerMap只否仅存在一个typeHandler，如果是，那么就是它了！(pickSoleHandler)
总结
本文在开头给两个注解@MappedTypes、@MappedJdbcTypes下了定义，强调了两者之间的不同之处。接着，结合案例对@MappedTypes的使用进行分析，论述了如何解决类膨胀的问题。之后，结合源码分析经过@MappedTypes、@MappedJdbcTypes注解的TypeHandler注册过程，得出了注解方式与注册主流程不强相关，不存在强依赖关系的结论。最后，通过源码对官网的阐述(Since Mybatis 3.4.0 however ...)进行回应，可知，Mybatis确实在向着越来越好用的方向演进...
