插件的配置與使用

在mybatis-config.xml配置文件中配置plugin結(jié)點(diǎn)，比如配置一個(gè)自定義的日志插件LogInterceptor和一個(gè)開源的分頁插件PageInterceptor：

<plugins> <plugin interceptor='com.crx.plugindemo.LogInterceptor'></plugin> <plugin interceptor='com.github.pagehelper.PageInterceptor'> <property name='helperDialect' value='oracle' /> </plugin></plugins>

插件的工作原理

借助責(zé)任鏈模式，定義一系列的過濾器，在查詢等方法執(zhí)行時(shí)進(jìn)行過濾，從而達(dá)到控制參數(shù)、調(diào)整查詢語句和控制查詢結(jié)果等作用。下面從插件的加載（初始化）、注冊(cè)和調(diào)用這三個(gè)方面闡述插件的工作原理。

過濾器的加載（初始化）

和其他配置信息一樣，過濾器的加載也會(huì)在myBatis讀取配置文件創(chuàng)建Configuration對(duì)象時(shí)進(jìn)行，相應(yīng)的信息存儲(chǔ)在Configuration的interceptorChain屬性中，InterceptorChain封裝了一個(gè)包含Interceptor的list：

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

在XMLConfigBuilder進(jìn)行解析配置文件時(shí)執(zhí)行pluginElement方法，生成過濾器實(shí)例，并添加到上述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); } }}

過濾器的注冊(cè)

可以為Executor、ParameterHandler、ResultSetHandler和StatementHandler四個(gè)接口注冊(cè)過濾器，注冊(cè)的時(shí)機(jī)也就是這四種接口的實(shí)現(xiàn)類的對(duì)象的生成時(shí)機(jī)，比如Executor的過濾器的注冊(cè)發(fā)生在SqlSessionFactory使用openSession方法構(gòu)建SqlSession的過程中（因?yàn)镾qlSession依賴一個(gè)Executor實(shí)例），ParameterHandler和StatementHandler的過濾器發(fā)生在doQuery等sql執(zhí)行方法執(zhí)行時(shí)注冊(cè)，而ResultHandler的過濾器的注冊(cè)則發(fā)生在查詢結(jié)果返回給客戶端的過程中。以Executor的過濾器的注冊(cè)為例，經(jīng)過了這樣的過程：

現(xiàn)在詳細(xì)的分析一下Plugin的wrap這個(gè)靜態(tài)的包裝方法：

public static Object wrap(Object target, Interceptor interceptor) { // 從定義的Interceptor實(shí)現(xiàn)類上的注解讀取需要攔截的類、方法 Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor); // Executor、ParameterHandler、ResultSetHandler、StatementHandler Class<?> type = target.getClass(); // 從當(dāng)前執(zhí)行的目標(biāo)類中進(jìn)行匹配，過濾出符合當(dāng)前目標(biāo)的的過濾器 Class<?>[] interfaces = getAllInterfaces(type, signatureMap); if (interfaces.length > 0) { // 動(dòng)態(tài)代理生成Executor的代理實(shí)例 return Proxy.newProxyInstance(type.getClassLoader(), interfaces, new Plugin(target, interceptor, signatureMap)); } return target;}

上述代碼中的getSignatureMap方法是解析Interceptor上面的注解的過程，從注解中讀取出需要攔截的方法，依據(jù)@Signature的三個(gè)變量類、方法method和參數(shù)args就能通過反射唯一的定位一個(gè)需要攔截的方法。

private static Map<Class<?>, Set<Method>> getSignatureMap(Interceptor interceptor) { Intercepts interceptsAnnotation = interceptor.getClass().getAnnotation(Intercepts.class); if (interceptsAnnotation == null) { throw new PluginException( 'No @Intercepts annotation was found in interceptor ' + interceptor.getClass().getName()); } Signature[] sigs = interceptsAnnotation.value(); Map<Class<?>, Set<Method>> signatureMap = new HashMap<>(); for (Signature sig : sigs) { Set<Method> 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 signatureMap;}

而getAllInterfaces方法是依據(jù)不同的目標(biāo)對(duì)象（Executor等四種）進(jìn)行過濾的過程，只給對(duì)應(yīng)的目標(biāo)進(jìn)行注冊(cè)：

private static Class<?>[] getAllInterfaces(Class<?> type, Map<Class<?>, Set<Method>> signatureMap) { Set<Class<?>> 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()]);}

至此，實(shí)際使用的Executor對(duì)象將是通過動(dòng)態(tài)代理生成的Plugin實(shí)例。

過濾器的調(diào)用

在第二步中完成了過濾器的注冊(cè)，在實(shí)際調(diào)用Executor時(shí)，將由實(shí)現(xiàn)了InvocationHandler接口的Plugin實(shí)例進(jìn)行接管，對(duì)Executor相應(yīng)方法方法的調(diào)用，將實(shí)際上調(diào)用動(dòng)態(tài)代理體系下的invoke方法：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { Set<Method> 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); }}

如前所述，插件的工作原理是基于責(zé)任鏈模式，可以注冊(cè)多個(gè)過濾器，層層包裝，最終由內(nèi)而外形成了一個(gè)近似裝飾器模式的責(zé)任鏈，最里面的基本實(shí)現(xiàn)是CachingExecutor：

從InterceptorChain的pluginAll方法可以看出這個(gè)結(jié)構(gòu)的構(gòu)造過程：

public Object pluginAll(Object target) { for (Interceptor interceptor : interceptors) { // 從這可以看出過濾器的傳遞的過程：動(dòng)態(tài)代理實(shí)例由內(nèi)而外層層包裝，類似于與裝飾器的結(jié)構(gòu)，基礎(chǔ) 實(shí)現(xiàn)是一個(gè)Executor target = interceptor.plugin(target); } return target;}

這種由內(nèi)而外的包裝的棧結(jié)構(gòu)從外向內(nèi)層層代理調(diào)用，完成了責(zé)任鏈任務(wù)的逐級(jí)推送。從這個(gè)注冊(cè)過程可以看到，在list中越前面的Interceptor越先被代理，在棧結(jié)構(gòu)中越處于底層，執(zhí)行的順序越靠后。造成了注冊(cè)順序和執(zhí)行順序相反的現(xiàn)象。

插件的典型案例：PageHelper

pagehelper是一個(gè)實(shí)現(xiàn)物理分頁效果的開源插件，并且在底層通過Dialect類適配了不同的數(shù)據(jù)庫，其主要作用是攔截sql查詢，構(gòu)造一個(gè)查詢總數(shù)的新的以'_COUNT'結(jié)尾的新sql，最終再進(jìn)行分頁查詢。

自定義插件

定義Interceptor接口的實(shí)現(xiàn)類并在其上使用@Intercepts和@Signature注解進(jìn)行過濾的類和方法，比如定義一個(gè)打日志的插件：

@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 {@Overridepublic Object intercept(Invocation invocation) throws Throwable {System.out.println('進(jìn)入了自定義的插件過濾器！');System.out.println('執(zhí)行的目標(biāo)是：' + invocation.getTarget());System.out.println('執(zhí)行的方法是：' + invocation.getMethod());System.out.println('執(zhí)行的參數(shù)是：' + invocation.getArgs());return invocation.proceed();}}

@Intercepts注解中包含了一個(gè)方法簽名數(shù)組，即@Signature數(shù)組，@Signature有三個(gè)屬性，type、method和args分別定義要攔截的類、方法名和參數(shù)，這樣就可以通過反射唯一的確定了要攔截的方法。type即為在工作原理分析中提到的Executor、ParameterHandler、ResultSetHandler和StatementHandler，method配置對(duì)應(yīng)接口中的方法。

到此這篇關(guān)于淺談myBatis中的插件機(jī)制的文章就介紹到這了,更多相關(guān)myBatis 插件機(jī)制內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！