回顾
上篇,我们分析了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
确实在向着越来越好用的方向演进...
网友评论