Executor攔截器高級(jí)教程QueryInterceptor的規(guī)范

更新時(shí)間：2018年12月26日 11:12:24 作者：isea533

今天小編就為大家分享一篇關(guān)于Executor攔截器高級(jí)教程QueryInterceptor的規(guī)范，小編覺(jué)得內(nèi)容挺不錯(cuò)的，現(xiàn)在分享給大家，具有很好的參考價(jià)值，需要的朋友一起跟隨小編來(lái)看看吧

Executor 攔截器高級(jí)教程 - QueryInterceptor 規(guī)范

這篇文檔涉及下面幾個(gè)方面

1. Executor query 方法介紹
2. 攔截器配置和調(diào)用順序
3. 攔截 query 方法的技巧
4. 攔截 query 方法的規(guī)范
5. 如何配置不同的 Executor 插件

1. Executor query 方法介紹

在 MyBatis 的攔截器的文檔部分，我們知道 Executor 中的 query 方法可以被攔截，如果你真正寫過(guò)這個(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è)方法。

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

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

攔截器的調(diào)用順序分為兩大種，第一種是攔截的不同對(duì)象，例如攔截 Executor 和攔截 StatementHandler 就屬于不同的攔截對(duì)象，這兩類的攔截器在整體執(zhí)行的邏輯上是不同的，在 Executor 中的 query 方法執(zhí)行過(guò)程中，會(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í)行過(guò)程中的一個(gè)子過(guò)程。所以這兩種不同類別的插件在配置時(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)該就很容易能看出來(lái)，將來(lái)執(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ì)攔截器的用法是最常見(jiàn)的一種用法，所以才會(huì)出現(xiàn)這種都能理解的執(zhí)行順序。但是分頁(yè)插件 5.0 不是這樣，這個(gè)插件顛覆了這種順序，這種顛覆其實(shí)也很普通，這也是本節(jié)要說(shuō)的技巧。

在我寫作 MyBatis 技術(shù)書籍的過(guò)程中（還沒(méi)寫完，已經(jīng)因?yàn)榉猪?yè)插件占用了幾周的寫作時(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)類只是這么簡(jiǎ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ù)方法被跳過(guò)了。但是由于這里的 executor 是代理對(duì)象，所以 6 個(gè)參數(shù)的 query 方法可以被代理了，這就擾亂了上一節(jié)中的執(zhí)行順序。

在上一節(jié)攔截器的例子中，做簡(jiǎn)單修改，將 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 中，沒(méi)有繼續(xù)執(zhí)行 4個(gè)參數(shù)方法，而是執(zhí)行了 6 個(gè)參數(shù)方法。但是 Interceptor1 攔截的 4 個(gè)參數(shù)的方法，所以 Interceptor1 就被跳過(guò)去了，整體的執(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í)行下去。

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

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

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

QueryInterceptor 的邏輯就是進(jìn)去的是 4 個(gè)參數(shù)的方法，出去的是 6 個(gè)參數(shù)的方法。這種處理方法不僅僅不方便和一般的 Excutor 攔截器搭配使用，當(dāng)出現(xiàn)兩個(gè)以上類似 QueryInterceptor 的插件時(shí)，由于接口變了，類似 QueryInterceptor 插件也無(wú)法連貫的執(zhí)行下去。因而有必要解決這個(gè)問(wèn)題。解決的辦法就是使用統(tǒng)一的規(guī)范。經(jīng)過(guò)規(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)用多次，在分頁(yè)插件中，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è)插件配置的靠后，是通過(guò) 4 個(gè)參數(shù)方法進(jìn)來(lái)的，我們就獲取這兩個(gè)對(duì)象。如果這個(gè)插件配置的靠前，已經(jīng)被別的攔截器處理成 6 個(gè)參數(shù)的方法了，那么我們直接從 args 中取出這兩個(gè)參數(shù)直接使用即可。取出這兩個(gè)參數(shù)就保證了當(dāng)其他攔截器對(duì)這兩個(gè)參數(shù)做過(guò)處理時(shí)，這兩個(gè)參數(shù)在這里會(huì)繼續(xù)生效。

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

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

這個(gè)規(guī)范對(duì)于已經(jīng)存在的插件來(lái)說(shuō)就沒(méi)法控制了，但是仍然可以通過(guò)配置順序來(lái)解決。

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

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

第 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)來(lái)，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í)行。

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

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

您可能感興趣的文章: