Executor 攔截器高級教程 - QueryInterceptor 規范
這篇文檔涉及下面幾個方面
1. Executor query 方法介紹
在 MyBatis 的攔截器的文檔部分，我們知道 Executor 中的 query 方法可以被攔截，如果你真正寫過這個方法的攔截器，你可能會知道在 Executor 中的 query 方法有兩個：
<E> List<E> query( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey cacheKey, BoundSql boundSql) throws SQLException;<E> List<E> query( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException;
這兩個方法的區別是第一個方法多兩個參數 CacheKey 和 BoundSql，在多數情況下，我們用攔截器的目的就是針對 SQL 做處理，如果能夠攔截第一個方法，可以直接得到 BoundSql 對象，就會很容易的得到執行的 SQL，也可以對 SQL 做處理。
雖然想的很好，但是 MyBatis 提供的 Exctutor 實現中，參數多的這個 query 方法都是被少的這個 query 方法在內部進行調用的。
在CachingExecutor中：
public <E> List<E> query( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { BoundSql boundSql = ms.getBoundSql(parameterObject); CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql); return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);} 在BaseExecutor中：
public <E> List<E> query( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { BoundSql boundSql = ms.getBoundSql(parameter); CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql); return query(ms, parameter, rowBounds, resultHandler, key, boundSql);} 上面這兩個方法一樣。由于第一個 query 方法在這里是內部調用，并且我們所有的攔截器都是層層代理的CachingExecutor或基于BaseExecutor的實現類，所以我們能攔截的就是參數少的這個方法。
分頁插件開始從Executor攔截開始就一直是攔截的參數少的這個方法。但是從5.0 版本開始，query 的這兩個方法都可以被攔截了。在講這個原理之前，我們先了解一下攔截器的執行順序。
2. 攔截器配置和調用順序
攔截器的調用順序分為兩大種，第一種是攔截的不同對象，例如攔截 Executor 和 攔截 StatementHandler 就屬于不同的攔截對象，這兩類的攔截器在整體執行的邏輯上是不同的，在 Executor 中的 query 方法執行過程中，會調用下面的代碼：
public <E> List<E> doQuery( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException { Statement stmt = null; try { Configuration configuration = ms.getConfiguration(); StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql); stmt = prepareStatement(handler, ms.getStatementLog()); return handler.<E>query(stmt, resultHandler); } finally { closeStatement(stmt); }}在這段代碼中，才會輪到 StatementHandler 去執行，StatementHandler 屬于 Executor 執行過程中的一個子過程。所以這兩種不同類別的插件在配置時，一定是先執行 Executor 的攔截器，然后才會輪到 StatementHandler。所以這種情況下配置攔截器的順序就不重要了，在 MyBatis 邏輯上就已經控制了先后順序。
第二種攔截器的順序就是指攔截同一種對象的同一個方法，例如都攔截 Executor 的 query 方法，這時你配置攔截器的順序就會對這里有影響了。假設有如下幾個攔截器，都是攔截的 Executor 的 query 方法。
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor2"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/></plugins>
在org.apache.ibatis.session.Configuration中有如下方法：
public void addInterceptor(Interceptor interceptor) { interceptorChain.addInterceptor(interceptor);} MyBatis 會按照攔截器配置的順序依次添加到interceptorChain中，其內部就是List<Interceptor> interceptors。再看 Configuration中創建 Executor 的代碼：
public Executor newExecutor(Transaction transaction, ExecutorType executorType) { executorType = executorType == null ? defaultExecutorType : executorType; executorType = executorType == null ? ExecutorType.SIMPLE : executorType; Executor executor; if (ExecutorType.BATCH == executorType) { executor = new BatchExecutor(this, transaction); } else if (ExecutorType.REUSE == executorType) { executor = new ReuseExecutor(this, transaction); } else { executor = new SimpleExecutor(this, transaction); } if (cacheEnabled) { executor = new CachingExecutor(executor); } executor = (Executor) interceptorChain.pluginAll(executor); return executor;}在調用 interceptorChain.pluginAll 之前，executor 就是前一節中的 CachingExecutor 或基于 BaseExecutor 的實現類。然后看 interceptorChain.pluginAll 方法：
public Object pluginAll(Object target) { for (Interceptor interceptor : interceptors) { target = interceptor.plugin(target); } return target;}前面我們配置攔截器的順序是1，2，3。在這里也會按照 1，2，3 的順序被層層代理，代理后的結構如下：
Interceptor3:{ Interceptor2: { Interceptor1: { target: Executor } }}從這個結構應該就很容易能看出來，將來執行的時候肯定是按照 3>2>1>Executor>1>2>3 的順序去執行的?？赡苡行┤瞬恢罏槭裁?>2>1>Executor之后會有1>2>3，這是因為使用代理時，調用完代理方法后，還能繼續進行其他處理。處理結束后，將代理方法的返回值繼續往外返回即可。例如：
Interceptor3 前置處理 Object result = Interceptor2..query(4個參數方法); Interceptor3 后續處理 return result;
對于 Interceptor2.invoke 方法也是相同的邏輯：
Interceptor2 前置處理 Object result = Interceptor1..query(4個參數方法); Interceptor2 后續處理 return result;
同理 Interceptor1.invoke ：
Interceptor1 前置處理 Object result = executor.query(4個參數方法); Interceptor1 后續處理 return result;
疊加到一起后，如下：
Interceptor3 前置處理Interceptor2 前置處理Interceptor1 前置處理 Object result = executor.query(4個參數方法); Interceptor1 后續處理 Interceptor2 后續處理 Interceptor3 后續處理 return result;
所以這個順序就是 3>2>1>Executor>1>2>3。
在你弄清楚這個邏輯后，再繼續往下看，因為后面的技巧會顛覆這個邏輯，所以才會有后面的規范以及如何配置不同的插件。
3. 攔截 query 方法的技巧
上一節的內容中，對攔截器的用法是最常見的一種用法，所以才會出現這種都能理解的執行順序。但是分頁插件 5.0 不是這樣，這個插件顛覆了這種順序，這種顛覆其實也很普通，這也是本節要說的技巧。
在我寫作 MyBatis 技術書籍的過程中（還沒寫完，已經因為分頁插件占用了幾周的寫作時間），我就在考慮為什么不能攔截第一個query（6個參數的）方法，如果能攔截這個方法，就可以直接拿到 BoundSql，然后處理 SQL 就很容易實現其他的操作。
在第1 節介紹為什么第一個query方法不能被攔截時，是因為下面這段代碼：
public <E> List<E> query( MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { BoundSql boundSql = ms.getBoundSql(parameter); CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql); return query(ms, parameter, rowBounds, resultHandler, key, boundSql);} 既然CachingExecutor或基于BaseExecutor的實現類只是這么簡單的調用兩個方法得到了BoundSql 和Cachekey，我們為什么不直接替代他們呢？
所以我們可以有類似下面的攔截器用法：
@Intercepts(@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}))public class QueryInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { Object[] args = invocation.getArgs(); MappedStatement ms = (MappedStatement) args[0]; Object parameterObject = args[1]; RowBounds rowBounds = (RowBounds) args[2]; ResultHandler resultHandler = (ResultHandler) args[3]; Executor executor = (Executor) invocation.getTarget(); BoundSql boundSql = ms.getBoundSql(parameterObject); //可以對參數做各種處理 CacheKey cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql); return executor.query(ms, parameterObject, rowBounds, resultHandler, cacheKey, boundSql); } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) { }}這個攔截器直接替代了原有 Executor 的部分邏輯，直接去調用了 6 個參數的方法，因而導致 4 個參數的后續方法被跳過了。但是由于這里的 executor 是代理對象，所以 6 個參數的 query 方法可以被代理了，這就擾亂了上一節中的執行順序。
在上一節攔截器的例子中，做簡單修改，將 ExecutorQueryInterceptor2 換成上面的 QueryInterceptor，配置如下：
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.QueryInterceptor"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/></plugins>
代理后的結構如下：
Interceptor3:{ QueryInterceptor: { Interceptor1: { target: Executor } }}這時，調用順序就變了，Interceptor3 執行順序如下：
Interceptor3 前置處理 Object result = QueryInterceptor.query(4個參數方法); Interceptor3 后續處理 return result;
QueryInterceptor.invoke 執行邏輯如下：
Interceptor2 前置處理 Object result = executor.query(6個參數方法); Interceptor2 后續處理 return result;
在 QueryInterceptor 中，沒有繼續執行 4個參數方法，而是執行了 6 個參數方法。但是 Interceptor1 攔截的 4 個參數的方法，所以 Interceptor1 就被跳過去了，整體的執行邏輯就變成下面這樣了：
Interceptor3 前置處理Interceptor2 前置處理Object result = executor.query(6個參數方法); Interceptor2 后續處理 Interceptor3 后續處理 return result;
如果 Interceptor1 攔截的是 6 個參數的方法，因為 QueryInterceptor 獲取的是 Interceptor1 代理的 executor 對象，那么 Interceptor1 就會被 QueryInterceptor 繼續執行下去。
分頁插件就是類似 QueryInterceptor 的執行邏輯，所以當你使用 5.0 版本之后的插件時，如果你還需要配置其他 Executor 的 query 插件，你就會遇到一些問題（可以解決，繼續往下看）。
如果你是自己開發的插件，那么你按照下一節的規范去開發也不會遇到問題。如果你使用的其他人提供的插件，按照第 5 節的配置順序也能解決問題。
4. 攔截 query 方法的規范
QueryInterceptor 的邏輯就是進去的是 4 個參數的方法，出去的是 6 個參數的方法。這種處理方法不僅僅不方便和一般的 Excutor 攔截器搭配使用，當出現兩個以上類似 QueryInterceptor 的插件時，由于接口變了，類似 QueryInterceptor 插件也無法連貫的執行下去。因而有必要解決這個問題。解決的辦法就是使用統一的規范。經過規范后 QueryInterceptor 如下：
@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 QueryInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { Object[] args = invocation.getArgs(); MappedStatement ms = (MappedStatement) args[0]; Object parameterObject = args[1]; RowBounds rowBounds = (RowBounds) args[2]; ResultHandler resultHandler = (ResultHandler) args[3]; Executor executor = (Executor) invocation.getTarget(); CacheKey cacheKey; BoundSql boundSql; //由于邏輯關系，只會進入一次 if(args.length == 4){ //4 個參數時 boundSql = ms.getBoundSql(parameterObject); cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql); } else { //6 個參數時 cacheKey = (CacheKey) args[4]; boundSql = (BoundSql) args[5]; } //TODO 自己要進行的各種處理 //注：下面的方法可以根據自己的邏輯調用多次，在分頁插件中，count 和 page 各調用了一次 return executor.query(ms, parameterObject, rowBounds, resultHandler, cacheKey, boundSql); } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) { }}注意兩個變化，第一個就是攔截器簽名同時攔截了 4 個 和 6 個參數的方法，這樣不管那個插件在前在后都會被執行。
第二個變化就是這段代碼：
CacheKey cacheKey;BoundSql boundSql;//由于邏輯關系，只會進入一次if(args.length == 4){ //4 個參數時 boundSql = ms.getBoundSql(parameterObject); cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);} else { //6 個參數時 cacheKey = (CacheKey) args[4]; boundSql = (BoundSql) args[5];}如果這個插件配置的靠后，是通過 4 個參數方法進來的，我們就獲取這兩個對象。如果這個插件配置的靠前，已經被別的攔截器處理成 6 個參數的方法了，那么我們直接從 args 中取出這兩個參數直接使用即可。取出這兩個參數就保證了當其他攔截器對這兩個參數做過處理時，這兩個參數在這里會繼續生效。
假設有個排序插件和分頁插件，排序插件將 BoundSql 修改為帶排序的 SQL 后，SQL 會繼續交給分頁插件使用。分頁插件的分頁 SQL 執行時，會保留排序去執行，這樣的規范就保證了兩個插件都能正常的執行下去。
所以如果大家想要使用這種方式去實現攔截器，建議大家遵守這個規范。
這個規范對于已經存在的插件來說就沒法控制了，但是仍然可以通過配置順序來解決。
5. 如何配置不同的 Executor 插件
當引入類似 QueryInterceptor 插件時，由于擾亂了原有的插件執行方式，當配置 Executor 順序不對時會導致插件無法生效。
第 4 節中的例子：
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.QueryInterceptor"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/></plugins>
首先執行順序為 3>Query>1>Executor，由于 Query 是 4 或 6 個參數進來，6 個參數出去。所以在 Query 前面執行的攔截器必須是 4 個的（Query 規范攔截器先后都能執行，需要根據邏輯配置先后）參數的，在 Query 后面執行的攔截器必須是 6 個參數的。
這個順序對應到配置順序時，也就是 4 個參數的配置在 QueryInterceptor 攔截器的下面，6 個參數的配置在 QueryInterceptor 攔截器的上面。按照這個順序進行配置時，就能保證攔截器都執行。
如果你想獲得如分頁插件（QueryInterceptor 規范）執行的 SQL，你就得按照 QueryInterceptor 規范去實現，否則只能配置在分頁插件的下面，也就只能獲得分頁處理前的 SQL。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對VeVb武林網的支持。
新聞熱點
疑難解答
圖片精選
