Executor 攔截器高級(jí)教程 - QueryInterceptor 規(guī)范
這篇文檔涉及下面幾個(gè)方面
1. Executor query 方法介紹
在 MyBatis 的攔截器的文檔部分，我們知道 Executor 中的 query 方法可以被攔截，如果你真正寫過這個(gè)方法的攔截器，你可能會(huì)知道在 Executor 中的 query 方法有兩個(gè)：
<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;
這兩個(gè)方法的區(qū)別是第一個(gè)方法多兩個(gè)參數(shù) CacheKey 和 BoundSql，在多數(shù)情況下，我們用攔截器的目的就是針對(duì) SQL 做處理，如果能夠攔截第一個(gè)方法，可以直接得到 BoundSql 對(duì)象，就會(huì)很容易的得到執(zhí)行的 SQL，也可以對(duì) SQL 做處理。
雖然想的很好，但是 MyBatis 提供的 Exctutor 實(shí)現(xiàn)中，參數(shù)多的這個(gè) query 方法都是被少的這個(gè) query 方法在內(nèi)部進(jìn)行調(diào)用的。
在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);} 上面這兩個(gè)方法一樣。由于第一個(gè) query 方法在這里是內(nèi)部調(diào)用，并且我們所有的攔截器都是層層代理的CachingExecutor或基于BaseExecutor的實(shí)現(xiàn)類，所以我們能攔截的就是參數(shù)少的這個(gè)方法。
分頁插件開始從Executor攔截開始就一直是攔截的參數(shù)少的這個(gè)方法。但是從5.0 版本開始，query 的這兩個(gè)方法都可以被攔截了。在講這個(gè)原理之前，我們先了解一下攔截器的執(zhí)行順序。
2. 攔截器配置和調(diào)用順序
攔截器的調(diào)用順序分為兩大種，第一種是攔截的不同對(duì)象，例如攔截 Executor 和 攔截 StatementHandler 就屬于不同的攔截對(duì)象，這兩類的攔截器在整體執(zhí)行的邏輯上是不同的，在 Executor 中的 query 方法執(zhí)行過程中，會(huì)調(diào)用下面的代碼：
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); }}在這段代碼中，才會(huì)輪到 StatementHandler 去執(zhí)行，StatementHandler 屬于 Executor 執(zhí)行過程中的一個(gè)子過程。所以這兩種不同類別的插件在配置時(shí)，一定是先執(zhí)行 Executor 的攔截器，然后才會(huì)輪到 StatementHandler。所以這種情況下配置攔截器的順序就不重要了，在 MyBatis 邏輯上就已經(jīng)控制了先后順序。
第二種攔截器的順序就是指攔截同一種對(duì)象的同一個(gè)方法，例如都攔截 Executor 的 query 方法，這時(shí)你配置攔截器的順序就會(huì)對(duì)這里有影響了。假設(shè)有如下幾個(gè)攔截器，都是攔截的 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 會(huì)按照攔截器配置的順序依次添加到interceptorChain中，其內(nèi)部就是List<Interceptor> interceptors。再看 Configuration中創(chuàng)建 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;}在調(diào)用 interceptorChain.pluginAll 之前，executor 就是前一節(jié)中的 CachingExecutor 或基于 BaseExecutor 的實(shí)現(xiàn)類。然后看 interceptorChain.pluginAll 方法：
public Object pluginAll(Object target) { for (Interceptor interceptor : interceptors) { target = interceptor.plugin(target); } return target;}前面我們配置攔截器的順序是1，2，3。在這里也會(huì)按照 1，2，3 的順序被層層代理，代理后的結(jié)構(gòu)如下：
Interceptor3:{ Interceptor2: { Interceptor1: { target: Executor } }}從這個(gè)結(jié)構(gòu)應(yīng)該就很容易能看出來，將來執(zhí)行的時(shí)候肯定是按照 3>2>1>Executor>1>2>3 的順序去執(zhí)行的?？赡苡行┤瞬恢罏槭裁?>2>1>Executor之后會(huì)有1>2>3，這是因?yàn)槭褂么頃r(shí)，調(diào)用完代理方法后，還能繼續(xù)進(jìn)行其他處理。處理結(jié)束后，將代理方法的返回值繼續(xù)往外返回即可。例如：
Interceptor3 前置處理 Object result = Interceptor2..query(4個(gè)參數(shù)方法); Interceptor3 后續(xù)處理 return result;
對(duì)于 Interceptor2.invoke 方法也是相同的邏輯：
Interceptor2 前置處理 Object result = Interceptor1..query(4個(gè)參數(shù)方法); Interceptor2 后續(xù)處理 return result;
同理 Interceptor1.invoke ：
Interceptor1 前置處理 Object result = executor.query(4個(gè)參數(shù)方法); Interceptor1 后續(xù)處理 return result;
疊加到一起后，如下：
Interceptor3 前置處理Interceptor2 前置處理Interceptor1 前置處理 Object result = executor.query(4個(gè)參數(shù)方法); Interceptor1 后續(xù)處理 Interceptor2 后續(xù)處理 Interceptor3 后續(xù)處理 return result;
所以這個(gè)順序就是 3>2>1>Executor>1>2>3。
在你弄清楚這個(gè)邏輯后，再繼續(xù)往下看，因?yàn)楹竺娴募记蓵?huì)顛覆這個(gè)邏輯，所以才會(huì)有后面的規(guī)范以及如何配置不同的插件。
3. 攔截 query 方法的技巧
上一節(jié)的內(nèi)容中，對(duì)攔截器的用法是最常見的一種用法，所以才會(huì)出現(xiàn)這種都能理解的執(zhí)行順序。但是分頁插件 5.0 不是這樣，這個(gè)插件顛覆了這種順序，這種顛覆其實(shí)也很普通，這也是本節(jié)要說的技巧。
在我寫作 MyBatis 技術(shù)書籍的過程中（還沒寫完，已經(jīng)因?yàn)榉猪摬寮加昧藥字艿膶懽鲿r(shí)間），我就在考慮為什么不能攔截第一個(gè)query（6個(gè)參數(shù)的）方法，如果能攔截這個(gè)方法，就可以直接拿到 BoundSql，然后處理 SQL 就很容易實(shí)現(xiàn)其他的操作。
在第1 節(jié)介紹為什么第一個(gè)query方法不能被攔截時(shí)，是因?yàn)橄旅孢@段代碼：
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的實(shí)現(xiàn)類只是這么簡單的調(diào)用兩個(gè)方法得到了BoundSql 和Cachekey，我們?yōu)槭裁床恢苯犹娲麄兡兀?/p>
所以我們可以有類似下面的攔截器用法：
@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); //可以對(duì)參數(shù)做各種處理 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) { }}這個(gè)攔截器直接替代了原有 Executor 的部分邏輯，直接去調(diào)用了 6 個(gè)參數(shù)的方法，因而導(dǎo)致 4 個(gè)參數(shù)的后續(xù)方法被跳過了。但是由于這里的 executor 是代理對(duì)象，所以 6 個(gè)參數(shù)的 query 方法可以被代理了，這就擾亂了上一節(jié)中的執(zhí)行順序。
在上一節(jié)攔截器的例子中，做簡單修改，將 ExecutorQueryInterceptor2 換成上面的 QueryInterceptor，配置如下：
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.QueryInterceptor"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/></plugins>
代理后的結(jié)構(gòu)如下：
Interceptor3:{ QueryInterceptor: { Interceptor1: { target: Executor } }}這時(shí)，調(diào)用順序就變了，Interceptor3 執(zhí)行順序如下：
Interceptor3 前置處理 Object result = QueryInterceptor.query(4個(gè)參數(shù)方法); Interceptor3 后續(xù)處理 return result;
QueryInterceptor.invoke 執(zhí)行邏輯如下：
Interceptor2 前置處理 Object result = executor.query(6個(gè)參數(shù)方法); Interceptor2 后續(xù)處理 return result;
在 QueryInterceptor 中，沒有繼續(xù)執(zhí)行 4個(gè)參數(shù)方法，而是執(zhí)行了 6 個(gè)參數(shù)方法。但是 Interceptor1 攔截的 4 個(gè)參數(shù)的方法，所以 Interceptor1 就被跳過去了，整體的執(zhí)行邏輯就變成下面這樣了：
Interceptor3 前置處理Interceptor2 前置處理Object result = executor.query(6個(gè)參數(shù)方法); Interceptor2 后續(xù)處理 Interceptor3 后續(xù)處理 return result;
如果 Interceptor1 攔截的是 6 個(gè)參數(shù)的方法，因?yàn)?QueryInterceptor 獲取的是 Interceptor1 代理的 executor 對(duì)象，那么 Interceptor1 就會(huì)被 QueryInterceptor 繼續(xù)執(zhí)行下去。
分頁插件就是類似 QueryInterceptor 的執(zhí)行邏輯，所以當(dāng)你使用 5.0 版本之后的插件時(shí)，如果你還需要配置其他 Executor 的 query 插件，你就會(huì)遇到一些問題（可以解決，繼續(xù)往下看）。
如果你是自己開發(fā)的插件，那么你按照下一節(jié)的規(guī)范去開發(fā)也不會(huì)遇到問題。如果你使用的其他人提供的插件，按照第 5 節(jié)的配置順序也能解決問題。
4. 攔截 query 方法的規(guī)范
QueryInterceptor 的邏輯就是進(jìn)去的是 4 個(gè)參數(shù)的方法，出去的是 6 個(gè)參數(shù)的方法。這種處理方法不僅僅不方便和一般的 Excutor 攔截器搭配使用，當(dāng)出現(xiàn)兩個(gè)以上類似 QueryInterceptor 的插件時(shí)，由于接口變了，類似 QueryInterceptor 插件也無法連貫的執(zhí)行下去。因而有必要解決這個(gè)問題。解決的辦法就是使用統(tǒng)一的規(guī)范。經(jīng)過規(guī)范后 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; //由于邏輯關(guān)系，只會(huì)進(jìn)入一次 if(args.length == 4){ //4 個(gè)參數(shù)時(shí) boundSql = ms.getBoundSql(parameterObject); cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql); } else { //6 個(gè)參數(shù)時(shí) cacheKey = (CacheKey) args[4]; boundSql = (BoundSql) args[5]; } //TODO 自己要進(jìn)行的各種處理 //注：下面的方法可以根據(jù)自己的邏輯調(diào)用多次，在分頁插件中，count 和 page 各調(diào)用了一次 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) { }}注意兩個(gè)變化，第一個(gè)就是攔截器簽名同時(shí)攔截了 4 個(gè) 和 6 個(gè)參數(shù)的方法，這樣不管那個(gè)插件在前在后都會(huì)被執(zhí)行。
第二個(gè)變化就是這段代碼：
CacheKey cacheKey;BoundSql boundSql;//由于邏輯關(guān)系，只會(huì)進(jìn)入一次if(args.length == 4){ //4 個(gè)參數(shù)時(shí) boundSql = ms.getBoundSql(parameterObject); cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);} else { //6 個(gè)參數(shù)時(shí) cacheKey = (CacheKey) args[4]; boundSql = (BoundSql) args[5];}如果這個(gè)插件配置的靠后，是通過 4 個(gè)參數(shù)方法進(jìn)來的，我們就獲取這兩個(gè)對(duì)象。如果這個(gè)插件配置的靠前，已經(jīng)被別的攔截器處理成 6 個(gè)參數(shù)的方法了，那么我們直接從 args 中取出這兩個(gè)參數(shù)直接使用即可。取出這兩個(gè)參數(shù)就保證了當(dāng)其他攔截器對(duì)這兩個(gè)參數(shù)做過處理時(shí)，這兩個(gè)參數(shù)在這里會(huì)繼續(xù)生效。
假設(shè)有個(gè)排序插件和分頁插件，排序插件將 BoundSql 修改為帶排序的 SQL 后，SQL 會(huì)繼續(xù)交給分頁插件使用。分頁插件的分頁 SQL 執(zhí)行時(shí)，會(huì)保留排序去執(zhí)行，這樣的規(guī)范就保證了兩個(gè)插件都能正常的執(zhí)行下去。
所以如果大家想要使用這種方式去實(shí)現(xiàn)攔截器，建議大家遵守這個(gè)規(guī)范。
這個(gè)規(guī)范對(duì)于已經(jīng)存在的插件來說就沒法控制了，但是仍然可以通過配置順序來解決。
5. 如何配置不同的 Executor 插件
當(dāng)引入類似 QueryInterceptor 插件時(shí)，由于擾亂了原有的插件執(zhí)行方式，當(dāng)配置 Executor 順序不對(duì)時(shí)會(huì)導(dǎo)致插件無法生效。
第 4 節(jié)中的例子：
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.QueryInterceptor"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/></plugins>
首先執(zhí)行順序?yàn)?3>Query>1>Executor，由于 Query 是 4 或 6 個(gè)參數(shù)進(jìn)來，6 個(gè)參數(shù)出去。所以在 Query 前面執(zhí)行的攔截器必須是 4 個(gè)的（Query 規(guī)范攔截器先后都能執(zhí)行，需要根據(jù)邏輯配置先后）參數(shù)的，在 Query 后面執(zhí)行的攔截器必須是 6 個(gè)參數(shù)的。
這個(gè)順序?qū)?yīng)到配置順序時(shí)，也就是 4 個(gè)參數(shù)的配置在 QueryInterceptor 攔截器的下面，6 個(gè)參數(shù)的配置在 QueryInterceptor 攔截器的上面。按照這個(gè)順序進(jìn)行配置時(shí)，就能保證攔截器都執(zhí)行。
如果你想獲得如分頁插件（QueryInterceptor 規(guī)范）執(zhí)行的 SQL，你就得按照 QueryInterceptor 規(guī)范去實(shí)現(xiàn)，否則只能配置在分頁插件的下面，也就只能獲得分頁處理前的 SQL。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)VeVb武林網(wǎng)的支持。
新聞熱點(diǎn)
疑難解答
圖片精選
