executor 攔截器高級教程 - queryinterceptor 規范
這篇文檔涉及下面幾個方面
- 1. executor query 方法介紹
- 2. 攔截器配置和調用順序
- 3. 攔截 query 方法的技巧
- 4. 攔截 query 方法的規范
- 5. 如何配置不同的 executor 插件
1. executor query 方法介紹
在 mybatis 的攔截器的文檔部分，我們知道 executor 中的 query 方法可以被攔截，如果你真正寫過這個方法的攔截器，你可能會知道在 executor 中的 query 方法有兩個：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
<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中：
|
1
2
3
4
5
6
7
8
9
|
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中：
|
1
2
3
4
5
6
7
8
9
|
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 方法執行過程中，會調用下面的代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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 方法。
|
1
2
3
4
5
|
<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中有如下方法：
|
1
2
3
|
public void addinterceptor(interceptor interceptor) { interceptorchain.addinterceptor(interceptor);} |
mybatis 會按照攔截器配置的順序依次添加到interceptorchain中，其內部就是list<interceptor> interceptors。再看 configuration中創建 executor 的代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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 方法：
|
1
2
3
4
5
6
|
public object pluginall(object target) { for (interceptor interceptor : interceptors) { target = interceptor.plugin(target); } return target;} |
前面我們配置攔截器的順序是1，2，3。在這里也會按照 1，2，3 的順序被層層代理，代理后的結構如下：
|
1
2
3
4
5
6
7
|
interceptor3:{ interceptor2: { interceptor1: { target: executor } }} |
從這個結構應該就很容易能看出來，將來執行的時候肯定是按照 3>2>1>executor>1>2>3 的順序去執行的。可能有些人不知道為什么3>2>1>executor之后會有1>2>3，這是因為使用代理時，調用完代理方法后，還能繼續進行其他處理。處理結束后，將代理方法的返回值繼續往外返回即可。例如：
|
1
2
3
4
|
interceptor3 前置處理 object result = interceptor2..query(4個參數方法); interceptor3 后續處理 return result; |
對于 interceptor2.invoke 方法也是相同的邏輯：
|
1
2
3
4
|
interceptor2 前置處理 object result = interceptor1..query(4個參數方法); interceptor2 后續處理 return result; |
同理 interceptor1.invoke ：
|
1
2
3
4
|
interceptor1 前置處理 object result = executor.query(4個參數方法); interceptor1 后續處理 return result; |
疊加到一起后，如下：
|
1
2
3
4
5
6
7
8
|
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方法不能被攔截時，是因為下面這段代碼：
|
1
2
3
4
5
6
7
8
9
|
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，我們為什么不直接替代他們呢？
所以我們可以有類似下面的攔截器用法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
@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，配置如下：
|
1
2
3
4
5
|
<plugins> <plugin interceptor="com.github.pagehelper.executorqueryinterceptor1"/> <plugin interceptor="com.github.pagehelper.queryinterceptor"/> <plugin interceptor="com.github.pagehelper.executorqueryinterceptor3"/></plugins> |
代理后的結構如下：
|
1
2
3
4
5
6
7
|
interceptor3:{ queryinterceptor: { interceptor1: { target: executor } }} |
這時，調用順序就變了，interceptor3 執行順序如下：
|
1
2
3
4
|
interceptor3 前置處理 object result = queryinterceptor.query(4個參數方法); interceptor3 后續處理 return result; |
queryinterceptor.invoke 執行邏輯如下：
|
1
2
3
4
|
interceptor2 前置處理 object result = executor.query(6個參數方法); interceptor2 后續處理 return result; |
在 queryinterceptor 中，沒有繼續執行 4個參數方法，而是執行了 6 個參數方法。但是 interceptor1 攔截的 4 個參數的方法，所以 interceptor1 就被跳過去了，整體的執行邏輯就變成下面這樣了：
|
1
2
3
4
5
6
|
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 如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
@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 個參數的方法，這樣不管那個插件在前在后都會被執行。
第二個變化就是這段代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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 節中的例子：
|
1
2
3
4
5
|
<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。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對服務器之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
原文鏈接：https://blog.csdn.net/isea533/article/details/53957330
