浅谈myBatis中的插件机制

浅谈myBatis中的插件机制

插件的配置与使用

在mybatis-config.xml配置文件中配置plugin结点，比如配置一个自定义的日志插件LogInterceptor和一个开源的分页插件PageInterceptor：

插件的工作原理

借助责任链模式，定义一系列的过滤器，在查询等方法执行时进行过滤，从而达到控制参数、调整查询语句和控制查询结果等作用。下面从插件的加载（初始化）、注册和调用这三个方面阐述插件的工作原理。

过滤器的加载（初始化）

和其他配置信息一样，过滤器的加载也会在myBatis读取配置文件创建Configuration对象时进行，相应的信息存储在Configuration的interceptorChain属性中，InterceptorChain封装了一个包含Interceptor的list：

private final List interceptors = new ArrayList<>();

在XMLConfigBuilder进行解析配置文件时执行pluginElement方法，生成过滤器实例，并添加到上述list中：

private void pluginElement(XNode parent) throws Exception {

if (parent != null) {

for (XNode child : parent.getChildren()) {

String interceptor = child.getStringAttribute("interceptor");

Properties properties = child.getChildrenAsProperties();

Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).getDeclaredConstructor()

.newInstance();

interceptorInstance.setProperties(properties);

configuration.addInterceptor(interceptorInstance);

}

}

}

过滤器的注册

可以为Executor、ParameterHandler、ResultSetHandler和StatementHandler四个接口注册过滤器，注册的时机也就是这四种接口的实现类的对象的生成时机，比如Executor的过滤器的注册发生在SqlSessionFactory使用openSession方法构建SqlSession的过程中（因为SqlSession依赖一个Executor实例），ParameterHandler和StatementHandler的过滤器发生在doQuery等sql执行方法执行时注册，而ResultHandler的过滤器的注册则发生在查询结果返回给客户端的过程中。以Executor的过滤器的注册为例，经过了这样的过程：

现在详细的分析一下Plugin的wrap这个静态的包装方法：

public static Object wrap(Object target, Interceptor interceptor) {

// 从定义的Interceptor实现类上的注解读取需要拦截的类、方法

Map, Set> signatureMap = getSignatureMap(interceptor);

// Executor、ParameterHandler、ResultSetHandler、StatementHandler

Class> type = target.getClass();

// 从当前执行的目标类中进行匹配，过滤出符合当前目标的的过滤器

Class>[] interfaces = getAllInterfaces(type, signatureMap);

if (interfaces.length > 0) {

// 动态代理生成Executor的代理实例

return Proxy.newProxyInstance(type.getClassLoader(), interfaces,

new Plugin(target, interceptor, signatureMap));

}

return target;

}

上述代码中的getSignatureMap方法是解析Interceptor上面的注解的过程，从注解中读取出需要拦截的方法，依据@Signature的三个变量类、方法method和参数args就能通过反射唯一的定位一个需要拦截的方法。

private static Map, Set> getSignatureMap(Interceptor interceptor) {

Intercepts interceptsAnnotation = interceptor.getClass().getAnnhttp://otation(Intercepts.class);

if (interceptsAnnotation == null) {

throw new PluginException(

"No @Intercepts annotation was found in interceptor " + interceptor.getClass().getName());

}

Signature[] sigs = interceptsAnnotation.value();

Map, Set> signatureMap = new HashMap<>();

for (Signature sig : sigs) {

Set methods = signatureMap.computeIfAbsent(sig.type(), k -> new HashSet<>());

try {

Method method = sig.type().getMethod(sig.method(), sig.args());

methods.add(method);

} catch (NoSuchMethodException e) {

throw new PluginException(

"Could not find method on " + sig.type() + " named " + sig.method() + ". Cause: " + e, e);

}

}

return signaturDNeBWeMap;

}

而getAllInterfaces方法是依据不同的目标对象（Executor等四种）进行过滤的过程，只给对应的目标进行注册：

private static Class>[] getAllInterfaces(Class> type, Map, Set> signatureMap) {

Set> interfaces = new HashSet<>();

while (type != null) {

for (Class> c : type.getInterfaces()) {

if (signatureMap.containsKey(c)) {

interfaces.add(c);

}

}

type = type.getSuperclass();

}

return interfaces.toArray(new Class>[interfaces.size()]);

}

至此，实际使用的Executor对象将是通过动态代理生成的Plugin实例。

过滤器的调用

在第二步中完成了过滤器的注册，在实际调用Executor时，将由实现了InvocationHandler接口的Plugin实例进行接管，对Executor相应方法方法的调用，将实际上调用动态代理体系下的invoke方法：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

try {

Set methods = signatureMap.get(method.getDeclaringClass());

if (methods != null && methods.contains(method)) {

Object result=interceptor.intercept(new Invocation(target, method, args));

return result;

}

return method.invoke(target, args);

} catch (Exception e) {

throw ExceptionUtil.unwrapThrowable(e);

}

}

如前所述，插件的工作原理是基于责任链模式，可以注册多个过滤器，层层包装，最终由内而外形成了一个近似装饰器模式的责任链，最里面的基本实现是CachingExecutor：

从InterceptorChain的pluginAll方法可以看出这个结构的构造过程：

public Object pluginAll(Object target) {

for (Interceptor interceptor : interceptors) {

// 从这可以看出过滤器的传递的过程：动态代理实例由内而外层层包装，类似于与装饰器的结构，基础 实现是一个Executor

target = interceptor.plugin(target);

}

return target;

}

这种由内而外的包装的栈结构从外向内层层代理调用，完成了责任链任务的逐级推送。从这个注册过程可以看到，在list中越前面的Interceptor越先被代理，在栈结构中越处于底层，执行的顺序越靠后。造成了注册顺序和执行顺序相反的现象。

插件的典型案例：PageHelper

pagehelper是一个实现物理分页效果的开源插件，并且在底层通过Dialect类适配了不同的数据库，其主要作用是拦截sql查询，构造一个查询总数的新的以"_COUNT"结尾的新sql，最终再进行分页查询。

自定义插件

定义Interceptor接口的实现类并在其上使用@Intercepts和@Signature注解进行过滤的类和方法，比如定义一个打日志的插件：

@Intercepts({

@Signature(type = Executor.class, method = "query", args = { MappedStatement.class, Object.class,

RowBounds.class, ResultHandler.class }),

@Signature(type = Executor.class, method = "query", args = { MappedStatement.class, Object.class,

RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class }), })

public class LogInterceptor implements Interceptor {

@Override

public Object intercept(Invocation invocation) throws Throwable {

System.out.println("进入了自定义的插件过滤器！");

System.out.println("执行的目标是：" + invocation.getTarget());

System.out.println("执行的方法是：" + invocation.getMethod());

System.out.println("执行的参数是：" + invocation.getArgs());

return invocation.proceed();

}

}

@Intercepts注解中包含了一个方法签名数组，即@Signature数组，@Signature有三个属性，type、method和args分别定义要拦截的类、方法名和参数，这样就可以通过反射唯一的确定了要拦截的方法。type即为在工作原理分析中提到的Executor、ParameterHandler、ResultSetHandler和StatementHandler，method配置对应接口中的方法。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。