QueryInterceptor的規(guī)范有哪些，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

我們提供的服務(wù)有：成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、慶云ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的慶云網(wǎng)站制作公司

1. Executor query 方法介紹

在 MyBatis 的攔截器的文檔部分，我們知道 Executor 中的 query 方法可以被攔截，如果你真正寫過這個方法的攔截器，你可能會知道在 Executor 中的 query 方法有兩個：

 List query(
   MappedStatement ms, 
   Object parameter, 
   RowBounds rowBounds, 
   ResultHandler resultHandler, 
   CacheKey cacheKey, 
   BoundSql boundSql) throws SQLException;
 List query(
   MappedStatement ms, 
   Object parameter, 
   RowBounds rowBounds, 
   ResultHandler resultHandler) throws SQLException;

這兩個方法的區(qū)別是第一個方法多兩個參數(shù) CacheKey 和 BoundSql，在多數(shù)情況下，我們用攔截器的目的就是針對 SQL 做處理，如果能夠攔截第一個方法，可以直接得到 BoundSql 對象，就會很容易的得到執(zhí)行的 SQL，也可以對 SQL 做處理。

雖然想的很好，但是 MyBatis 提供的 Exctutor 實現(xiàn)中，參數(shù)多的這個 query 方法都是被少的這個 query 方法在內(nèi)部進(jìn)行調(diào)用的。

在CachingExecutor中：

public  List 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  List 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 方法在這里是內(nèi)部調(diào)用，并且我們所有的攔截器都是層層代理的CachingExecutor或基于BaseExecutor的實現(xiàn)類，所以我們能攔截的就是參數(shù)少的這個方法。

分頁插件開始從Executor攔截開始就一直是攔截的參數(shù)少的這個方法。但是從5.0 版本開始，query 的這兩個方法都可以被攔截了。在講這個原理之前，我們先了解一下攔截器的執(zhí)行順序。

2. 攔截器配置和調(diào)用順序

攔截器的調(diào)用順序分為兩大種，第一種是攔截的不同對象，例如攔截 Executor 和 攔截 StatementHandler 就屬于不同的攔截對象，這兩類的攔截器在整體執(zhí)行的邏輯上是不同的，在 Executor 中的 query 方法執(zhí)行過程中，會調(diào)用下面的代碼：

public  List 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.query(stmt, resultHandler);
  } finally {
    closeStatement(stmt);
  }
}

在這段代碼中，才會輪到 StatementHandler 去執(zhí)行，StatementHandler 屬于 Executor 執(zhí)行過程中的一個子過程。所以這兩種不同類別的插件在配置時，一定是先執(zhí)行 Executor 的攔截器，然后才會輪到 StatementHandler。所以這種情況下配置攔截器的順序就不重要了，在 MyBatis 邏輯上就已經(jīng)控制了先后順序。

第二種攔截器的順序就是指攔截同一種對象的同一個方法，例如都攔截 Executor 的 query 方法，這時你配置攔截器的順序就會對這里有影響了。假設(shè)有如下幾個攔截器，都是攔截的 Executor 的 query 方法。

在org.apache.ibatis.session.Configuration中有如下方法：

public void addInterceptor(Interceptor interceptor) {
  interceptorChain.addInterceptor(interceptor);
}

MyBatis 會按照攔截器配置的順序依次添加到interceptorChain中，其內(nèi)部就是List 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 的實現(xiàn)類。然后看 interceptorChain.pluginAll 方法：

public Object pluginAll(Object target) {
  for (Interceptor interceptor : interceptors) {
    target = interceptor.plugin(target);
  }
  return target;
}

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

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

從這個結(jié)構(gòu)應(yīng)該就很容易能看出來，將來執(zhí)行的時候肯定是按照 3>2>1>Executor>1>2>3 的順序去執(zhí)行的?？赡苡行┤瞬恢罏槭裁?>2>1>Executor之后會有1>2>3，這是因為使用代理時，調(diào)用完代理方法后，還能繼續(xù)進(jìn)行其他處理。處理結(jié)束后，將代理方法的返回值繼續(xù)往外返回即可。例如：

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

對于 Interceptor2.invoke 方法也是相同的邏輯：

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

同理 Interceptor1.invoke ：

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

疊加到一起后，如下：

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

所以這個順序就是 3>2>1>Executor>1>2>3。

在你弄清楚這個邏輯后，再繼續(xù)往下看，因為后面的技巧會顛覆這個邏輯，所以才會有后面的規(guī)范以及如何配置不同的插件。

3. 攔截 query 方法的技巧

上一節(jié)的內(nèi)容中，對攔截器的用法是最常見的一種用法，所以才會出現(xiàn)這種都能理解的執(zhí)行順序。但是分頁插件 5.0 不是這樣，這個插件顛覆了這種順序，這種顛覆其實也很普通，這也是本節(jié)要說的技巧。

在我寫作 MyBatis 技術(shù)書籍的過程中（還沒寫完，已經(jīng)因為分頁插件占用了幾周的寫作時間），我就在考慮為什么不能攔截第一個query（6個參數(shù)的）方法，如果能攔截這個方法，就可以直接拿到 BoundSql，然后處理 SQL 就很容易實現(xiàn)其他的操作。

在第1 節(jié)介紹為什么第一個query方法不能被攔截時，是因為下面這段代碼：

public  List 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的實現(xiàn)類只是這么簡單的調(diào)用兩個方法得到了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);
    //可以對參數(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) {
  }
}

這個攔截器直接替代了原有 Executor 的部分邏輯，直接去調(diào)用了 6 個參數(shù)的方法，因而導(dǎo)致 4 個參數(shù)的后續(xù)方法被跳過了。但是由于這里的 executor 是代理對象，所以 6 個參數(shù)的 query 方法可以被代理了，這就擾亂了上一節(jié)中的執(zhí)行順序。

在上一節(jié)攔截器的例子中，做簡單修改，將 ExecutorQueryInterceptor2 換成上面的 QueryInterceptor，配置如下：

代理后的結(jié)構(gòu)如下：

Interceptor3:{
  QueryInterceptor: {
    Interceptor1: {
      target: Executor
    }
  }
}

這時，調(diào)用順序就變了，Interceptor3 執(zhí)行順序如下：

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

QueryInterceptor.invoke 執(zhí)行邏輯如下：

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

在 QueryInterceptor 中，沒有繼續(xù)執(zhí)行 4個參數(shù)方法，而是執(zhí)行了 6 個參數(shù)方法。但是 Interceptor1 攔截的 4 個參數(shù)的方法，所以 Interceptor1 就被跳過去了，整體的執(zhí)行邏輯就變成下面這樣了：

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

如果 Interceptor1 攔截的是 6 個參數(shù)的方法，因為 QueryInterceptor 獲取的是 Interceptor1 代理的 executor 對象，那么 Interceptor1 就會被 QueryInterceptor 繼續(xù)執(zhí)行下去。

分頁插件就是類似 QueryInterceptor 的執(zhí)行邏輯，所以當(dāng)你使用 5.0 版本之后的插件時，如果你還需要配置其他 Executor 的 query 插件，你就會遇到一些問題（可以解決，繼續(xù)往下看）。

如果你是自己開發(fā)的插件，那么你按照下一節(jié)的規(guī)范去開發(fā)也不會遇到問題。如果你使用的其他人提供的插件，按照第 5 節(jié)的配置順序也能解決問題。

4. 攔截 query 方法的規(guī)范

QueryInterceptor 的邏輯就是進(jìn)去的是 4 個參數(shù)的方法，出去的是 6 個參數(shù)的方法。這種處理方法不僅僅不方便和一般的 Excutor 攔截器搭配使用，當(dāng)出現(xiàn)兩個以上類似 QueryInterceptor 的插件時，由于接口變了，類似 QueryInterceptor 插件也無法連貫的執(zhí)行下去。因而有必要解決這個問題。解決的辦法就是使用統(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)系，只會進(jìn)入一次
    if(args.length == 4){
      //4 個參數(shù)時
      boundSql = ms.getBoundSql(parameterObject);
      cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);
    } else {
      //6 個參數(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) {
  }
}

注意兩個變化，第一個就是攔截器簽名同時攔截了 4 個 和 6 個參數(shù)的方法，這樣不管那個插件在前在后都會被執(zhí)行。

第二個變化就是這段代碼：

CacheKey cacheKey;
BoundSql boundSql;
//由于邏輯關(guān)系，只會進(jìn)入一次
if(args.length == 4){
  //4 個參數(shù)時
  boundSql = ms.getBoundSql(parameterObject);
  cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);
} else {
  //6 個參數(shù)時
  cacheKey = (CacheKey) args[4];
  boundSql = (BoundSql) args[5];
}

如果這個插件配置的靠后，是通過 4 個參數(shù)方法進(jìn)來的，我們就獲取這兩個對象。如果這個插件配置的靠前，已經(jīng)被別的攔截器處理成 6 個參數(shù)的方法了，那么我們直接從 args 中取出這兩個參數(shù)直接使用即可。取出這兩個參數(shù)就保證了當(dāng)其他攔截器對這兩個參數(shù)做過處理時，這兩個參數(shù)在這里會繼續(xù)生效。

假設(shè)有個排序插件和分頁插件，排序插件將 BoundSql 修改為帶排序的 SQL 后，SQL 會繼續(xù)交給分頁插件使用。分頁插件的分頁 SQL 執(zhí)行時，會保留排序去執(zhí)行，這樣的規(guī)范就保證了兩個插件都能正常的執(zhí)行下去。

所以如果大家想要使用這種方式去實現(xiàn)攔截器，建議大家遵守這個規(guī)范。

這個規(guī)范對于已經(jīng)存在的插件來說就沒法控制了，但是仍然可以通過配置順序來解決。

5. 如何配置不同的 Executor 插件

當(dāng)引入類似 QueryInterceptor 插件時，由于擾亂了原有的插件執(zhí)行方式，當(dāng)配置 Executor 順序不對時會導(dǎo)致插件無法生效。

第 4 節(jié)中的例子：

首先執(zhí)行順序為 3>Query>1>Executor，由于 Query 是 4 或 6 個參數(shù)進(jìn)來，6 個參數(shù)出去。所以在 Query 前面執(zhí)行的攔截器必須是 4 個的（Query 規(guī)范攔截器先后都能執(zhí)行，需要根據(jù)邏輯配置先后）參數(shù)的，在 Query 后面執(zhí)行的攔截器必須是 6 個參數(shù)的。

這個順序?qū)?yīng)到配置順序時，也就是 4 個參數(shù)的配置在 QueryInterceptor 攔截器的下面，6 個參數(shù)的配置在 QueryInterceptor 攔截器的上面。按照這個順序進(jìn)行配置時，就能保證攔截器都執(zhí)行。

如果你想獲得如分頁插件（QueryInterceptor 規(guī)范）執(zhí)行的 SQL，你就得按照 QueryInterceptor 規(guī)范去實現(xiàn)，否則只能配置在分頁插件的下面，也就只能獲得分頁處理前的 SQL。

看完上述內(nèi)容，你們掌握QueryInterceptor的規(guī)范有哪些的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！