@Intercepts({@Signature(
? type= Executor.class,
? method = "update",
? args = {MappedStatement.class,Object.class})})
public class ExamplePlugin implements Interceptor {
? private Properties properties = new Properties();
? public Object intercept(Invocation invocation) throws Throwable {
? ? // implement pre processing if need
? ? Object returnObject = invocation.proceed();
? ? // implement post processing if need
? ? return returnObject;
? }
? public void setProperties(Properties properties) {
? ? this.properties = properties;
? }
}

然后在mybatis的配置文件中，添加插件的對(duì)應(yīng)配置即可。

<!-- mybatis-config.xml -->
<plugins>
? <plugin interceptor="org.mybatis.example.ExamplePlugin">
? ? <property name="someProperty" value="100"/>
? </plugin>
</plugins>

我們也可以在代碼中添加，下面給出在spring中

//通過spring查找SqlSessionFactory對(duì)象的邏輯在此省略
SqlSessionFactory sqlSessionFactory = (SqlSessionFactory) var3;
org.apache.ibatis.session.Configuration c = sqlSessionFactory.getConfiguration();
c.addInterceptor(interceptor);

分別加上處理的業(yè)務(wù)邏輯，這個(gè)攔截器就可以使用了。

2、需要注意的地方

第一節(jié)簡(jiǎn)單介紹了，攔截器的使用方法，但在實(shí)際項(xiàng)目中這樣還遠(yuǎn)遠(yuǎn)不夠。

筆者在本節(jié)列舉了一些需要注意的地方，供大家思考討論。

攔截器的執(zhí)行順序

攔截器的調(diào)用順序分為兩大種，第一種是攔截的不同對(duì)象，第二種是指攔截同一種對(duì)象的同一個(gè)方法。

第一種情況，例如攔截 Executor 和攔截 StatementHandler 就屬于不同的攔截對(duì)象，這兩類的攔截器在整體執(zhí)行的邏輯上是不同的。

StatementHandler 屬于 Executor 執(zhí)行過程中的一個(gè)子過程。

所以這兩種不同類別的插件在配置時(shí)，一定是先執(zhí)行 Executor 的攔截器，然后才會(huì)輪到 StatementHandler。

所以這種情況下配置攔截器的順序就不重要了，在 MyBatis 邏輯上就已經(jīng)控制了先后順序。

第二種情況，例如都攔截 Executor 的 query 方法，這時(shí)你配置攔截器的順序就會(huì)對(duì)這里有影響了。比如配置如下。

<plugins>
? ? <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/>
? ? <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor2"/>
? ? <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/>
</plugins>

前面我們配置攔截器的順序是1，2，3。在這里也會(huì)按照 1，2，3 的順序被層層代理，代理后的結(jié)構(gòu)如下：

Interceptor3:{
? ? Interceptor2: {
? ? ? ? Interceptor1: {
? ? ? ? ? ? target: Executor
? ? ? ? }
? ? }
}

然后到執(zhí)行的邏輯：

Interceptor3 前置處理
Interceptor2 前置處理
Interceptor1 前置處理
Object result = executor.query(4個(gè)參數(shù)方法);
Interceptor1 后續(xù)處理
Interceptor2 后續(xù)處理
Interceptor3 后續(xù)處理
return result;

順序就是 3>2>1>Executor>1>2>3。MyBatis的攔截器采用責(zé)任鏈設(shè)計(jì)模式，多個(gè)攔截器之間的責(zé)任鏈?zhǔn)峭ㄟ^動(dòng)態(tài)代理組織的。

我們一般都會(huì)在攔截器中的intercept方法中往往會(huì)有invocation.proceed()語(yǔ)句，其作用是將攔截器責(zé)任鏈向后傳遞，本質(zhì)上便是動(dòng)態(tài)代理的invoke。

與常用插件的整合遇到的問題

pageHelper造成分頁(yè)失效的問題

通過查看pagehelper源碼，可以看到其inercept方法直接獲取了excutor然后開始分頁(yè)查詢，當(dāng)查詢到結(jié)果時(shí)，便返回了。

就是pagehelper的intercept方法中沒有invocation.proceed()，這意味著什么？

//com.github.pagehelper.PageInterceptor#intercept
.....
? ? ? ? ? ? ? ? resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);
? ? ? ? ? ? }
? ? ? ? ? ? return dialect.afterPage(resultList, parameter, rowBounds);
? ? ? ? } finally {
? ? ? ? ? ? dialect.afterAll();
? ? ? ? }

這意味著pagehelper沒有繼續(xù)向后傳遞責(zé)任鏈，而是自行處理直接返回。

由此，我們可以猜出該問題大概率與攔截器的執(zhí)行順序有關(guān)。

通過斷點(diǎn)調(diào)試，驗(yàn)證了該猜想，當(dāng)遇到分頁(yè)查詢時(shí)，執(zhí)行到pagehelper就結(jié)束了，沒有進(jìn)入我們的自定義攔截器。這就可能造成我們自定義攔截器失效。

解決方案

因?yàn)镻ageHelper是Excetor類型的攔截器，所以我們?nèi)绻胍赑ageHelper攔截器前面執(zhí)行，就必須要將我們自己的攔截器添加到他的攔截器后面。

這里只介紹最簡(jiǎn)單最優(yōu)雅的一種方式：

注冊(cè)一個(gè)ApplicationListener監(jiān)聽器，監(jiān)聽 ContextRefreshedEvent 事件，當(dāng)所有的bean都初始化完成后（即PageHelper也已經(jīng)注冊(cè)好了），再把我們的自定義 MyBatis 攔截器注冊(cè)到 SqlSessionFactory 中。

可以提升的點(diǎn)

Interceptor接口提供了三個(gè)方法分別是攔截器處理邏輯的主要方法、判斷是否要進(jìn)行攔截，然后做出決定是否生成一個(gè)代理的方法及設(shè)置參數(shù)的方法。

package org.apache.ibatis.plugin;

import java.util.Properties;

public interface Interceptor {

? Object intercept(Invocation invocation) throws Throwable;

? default Object plugin(Object target) {
? ? return Plugin.wrap(target, this);
? }

? default void setProperties(Properties properties) {
? ? // NOP
? }
}

這里說的提升點(diǎn)，就是在實(shí)現(xiàn)接口的實(shí)現(xiàn)類中，我們可以在plugin方法里加上一個(gè)判斷，因?yàn)槟J(rèn)情況下，攔截器根據(jù)順序攔截后，就可以去處理對(duì)應(yīng)邏輯了，這里加上一個(gè)判斷攔截的條件，可以減少代理類的創(chuàng)建。

? ? @Override
? ? public Object plugin(Object target) {
? ? ? ? if (target instanceof StatementHandler && checkIfNeeded((StatementHandler) target)) {
? ? ? ? ? ? return Plugin.wrap(target, this);
? ? ? ? } else {
? ? ? ? ? ? return target;
? ? ? ? }
? ? }

參考文檔：