Executor攔截器高級教程QueryInterceptor的規(guī)范
Executor 攔截器高級教程 - QueryInterceptor 規(guī)范
這篇文檔涉及下面幾個方面
- 1. Executor query 方法介紹
- 2. 攔截器配置和調(diào)用順序
- 3. 攔截 query 方法的技巧
- 4. 攔截 query 方法的規(guī)范
- 5. 如何配置不同的 Executor 插件
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;
這兩個方法的區(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 <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 方法在這里是內(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 <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 去執(zhí)行，StatementHandler 屬于 Executor 執(zhí)行過程中的一個子過程。所以這兩種不同類別的插件在配置時，一定是先執(zhí)行 Executor 的攔截器，然后才會輪到 StatementHandler。所以這種情況下配置攔截器的順序就不重要了，在 MyBatis 邏輯上就已經(jīng)控制了先后順序。
第二種攔截器的順序就是指攔截同一種對象的同一個方法，例如都攔截 Executor 的 query 方法，這時你配置攔截器的順序就會對這里有影響了。假設(shè)有如下幾個攔截器，都是攔截的 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中，其內(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 的實現(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 <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的實現(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，配置如下：
<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
}
}
}
這時，調(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é)中的例子：
<plugins> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/> <plugin interceptor="com.github.pagehelper.QueryInterceptor"/> <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/> </plugins>
首先執(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。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接
- Java自帶定時任務(wù)ScheduledThreadPoolExecutor實現(xiàn)定時器和延時加載功能
- Java并發(fā)之線程池Executor框架的深入理解
- Spring線程池ThreadPoolTaskExecutor配置詳情
- Java ExecutorService四種線程池使用詳解
- ScheduledExecutorService任務(wù)定時代碼示例
- 基于ScheduledExecutorService的兩種方法(詳解)
- ThreadPoolExecutor線程池原理及其execute方法(詳解)
- 簡單談?wù)凾hreadPoolExecutor線程池之submit方法
- java ThreadPoolExecutor 并發(fā)調(diào)用實例詳解
- 詳解Java利用ExecutorService實現(xiàn)同步執(zhí)行大量線程
相關(guān)文章
本文小編將向大家介紹的是如何利用Java輸出各種不同的形狀，本文一共介紹了七種有趣的形狀，感興趣的小伙伴趕快收藏起來吧2021-09-09
SpringBoot接口參數(shù)的默認(rèn)值與必要性最佳實踐記錄
這篇文章主要介紹了SpringBoot接口參數(shù)的默認(rèn)值與必要性,通過合理設(shè)置接口參數(shù)的默認(rèn)值和必要性,我們可以創(chuàng)建出既健壯又靈活的?RESTful?API,需要的朋友可以參考下2024-08-08
這篇文章主要介紹了Spring的事務(wù)機(jī)制實例代碼，分享了相關(guān)代碼示例，小編覺得還是挺不錯的，具有一定借鑒價值，需要的朋友可以參考下2018-02-02
這篇文章主要介紹了Java中串行接口調(diào)用優(yōu)化方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-05-05
java輸入時如何通過回車(enter)來結(jié)束輸入
這篇文章主要介紹了java輸入時如何通過回車(enter)來結(jié)束輸入，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-05-05
這篇文章主要介紹了Java中的異常Exception與處理方式詳解, Java語言中，將程序執(zhí)行中發(fā)生的不正常情況稱為"異常"(開發(fā)過程中的語法錯誤和邏輯錯誤不是異常),需要的朋友可以參考下2024-01-01
SpringCloud超詳細(xì)講解Feign聲明式服務(wù)調(diào)用
Feign可以把Rest的請求進(jìn)行隱藏，偽裝成類似Spring?MVC的Controller一樣。不用再自己拼接url，拼接參數(shù)等等操作，一切都交給Feign去做2022-06-06
這篇文章主要介紹了在Java程序中運用Redis緩存對象的方法，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-03-03
詳解Springboot如何優(yōu)雅的進(jìn)行數(shù)據(jù)校驗
基于?Spring?Boot?，如何“優(yōu)雅”的進(jìn)行數(shù)據(jù)校驗?zāi)?，本文將待大家詳?xì)介紹Springboot如何優(yōu)雅的進(jìn)行數(shù)據(jù)校驗，文中有詳細(xì)的代碼示例和流程步驟,需要的朋友可以參考下2023-06-06
Java實現(xiàn)批量查找與替換Excel文本的思路詳解
在 Java 中,可以通過find和replace的方法來查找和替換單元格的數(shù)據(jù),下面小編將以Excel文件為例為大家介紹如何實現(xiàn)Excel文件內(nèi)容的批量替換,感興趣的朋友跟隨小編一起看看吧2023-10-10