讓我們再來回顧一下之前我們曾經(jīng)用過的一張Action LifeCycle的圖：



圖中，我們可以發(fā)現(xiàn)，Struts2的Interceptor一層一層，把Action包裹在最里面。這樣的結構，大概有以下一些特點：

1. 整個結構就如同一個堆棧，除了Action以外，堆棧中的其他元素是Interceptor

2. Action位于堆棧的底部。由于堆棧"先進后出"的特性，如果我們試圖把Action拿出來執(zhí)行，我們必須首先把位于Action上端的Interceptor拿出來執(zhí)行。這樣，整個執(zhí)行就形成了一個遞歸調用

3. 每個位于堆棧中的Interceptor，除了需要完成它自身的邏輯，還需要完成一個特殊的執(zhí)行職責。這個執(zhí)行職責有3種選擇：

1) 中止整個執(zhí)行，直接返回一個字符串作為resultCode

2) 通過遞歸調用負責調用堆棧中下一個Interceptor的執(zhí)行

3) 如果在堆棧內(nèi)已經(jīng)不存在任何的Interceptor，調用Action


Struts2的攔截器結構的設計，實際上是一個典型的責任鏈模式的應用。首先將整個執(zhí)行劃分成若干相同類型的元素，每個元素具備不同的邏輯責任，并將他們納入到一個鏈式的數(shù)據(jù)結構中（我們可以把堆棧結構也看作是一個遞歸的鏈式結構），而每個元素又有責任負責鏈式結構中下一個元素的執(zhí)行調用。

這樣的設計，從代碼重構的角度來看，實際上是將一個復雜的系統(tǒng)，分而治之，從而使得每個部分的邏輯能夠高度重用并具備高度可擴展性。所以，Interceptor結構實在是Struts2/Xwork設計中的精華之筆。

Interceptor的定義

我們來看一下Interceptor的接口的定義：



Interceptor的接口定義沒有什么特別的地方，除了init和destory方法以外，intercept方法是實現(xiàn)整個攔截器機制的核心方法。而它所依賴的參數(shù)ActionInvocation則是我們之前章節(jié)中曾經(jīng)提到過的著名的Action調度者。

我們再來看看一個典型的Interceptor的抽象實現(xiàn)類：



在這個實現(xiàn)類中，實際上已經(jīng)實現(xiàn)了最簡單的攔截器的雛形。或許大家對這樣的代碼還比較陌生，這沒有關系。我在這里需要指出的是一個很重要的方法 invocation.invoke()。這是ActionInvocation中的方法，而ActionInvocation是Action調度者，所 以這個方法具備以下2層含義：

1. 如果攔截器堆棧中還有其他的Interceptor，那么invocation.invoke()將調用堆棧中下一個Interceptor的執(zhí)行。

2. 如果攔截器堆棧中只有Action了，那么invocation.invoke()將調用Action執(zhí)行。

所以，我們可以發(fā)現(xiàn)，invocation.invoke()這個方法其實是整個攔截器框架的實現(xiàn)核心。基于這樣的實現(xiàn)機制，我們還可以得到下面2個非常重要的推論：

1. 如果在攔截器中，我們不使用invocation.invoke()來完成堆棧中下一個元素的調用，而是直接返回一個字符串作為執(zhí)行結果，那么整個執(zhí)行將被中止。

2. 我們可以以invocation.invoke()為界，將攔截器中的代碼分成2個部分，在invocation.invoke()之前的代碼，將會在 Action之前被依次執(zhí)行，而在invocation.invoke()之后的代碼，將會在Action之后被逆序執(zhí)行。

由此，我們就可以通過invocation.invoke()作為Action代碼真正的攔截點，從而實現(xiàn)AOP。

Interceptor攔截類型

從上面的分析，我們知道，整個攔截器的核心部分是invocation.invoke()這個函數(shù)的調用位置。事實上，我們也正式根據(jù)這句代碼的調用位置，來進行攔截類型的區(qū)分的。在Struts2中，Interceptor的攔截類型，分成以下三類：

1. before

before攔截，是指在攔截器中定義的代碼，它們存在于invocation.invoke()代碼執(zhí)行之前。這些代碼，將依照攔截器定義的順序，順序執(zhí)行。

2. after

after攔截，是指在攔截器中定義的代碼，它們存在于invocation.invoke()代碼執(zhí)行之后。這些代碼，將一招攔截器定義的順序，逆序執(zhí)行。

3. PreResultListener

有的時候，before攔截和after攔截對我們來說是不夠的，因為我們需要在Action執(zhí)行完之后，但是還沒有回到視圖層之前，做一些事 情。Struts2同樣支持這樣的攔截，這種攔截方式，是通過在攔截器中注冊一個PreResultListener的接口來實現(xiàn)的。



在這里，我們看到，Struts2能夠支持如此多的攔截類型，與其本身的數(shù)據(jù)結構和整體設計有很大的關系。正如我在之前的文章中所提到的：



我們可以看到，Struts2對于整個執(zhí)行的劃分，從Interceptor到Action一直到Result，每一層都職責明確。不僅如此，Struts2還為每一個層次之前都設立了恰如其分的插入點。使得整個Action層的擴展性得到了史無前例的提升。

Interceptor執(zhí)行順序

Interceptor的執(zhí)行順序或許是我們在整個過程中最最關心的部分。根據(jù)上面所提到的概念，我們實際上已經(jīng)能夠大致明白了Interceptor的執(zhí)行機理。我們來看看Struts2的Reference對Interceptor執(zhí)行順序的一個形象的例子。

如果我們有一個interceptor-stack的定義如下：



那么，整個執(zhí)行的順序大概像這樣：



在這里，我稍微改了一下Struts2的Reference中的執(zhí)行順序示例，使得整個執(zhí)行順序更加能夠被理解。我們可以看到，遞歸調用保證了各種各樣的攔截類型的執(zhí)行能夠井井有條。

請注意在這里，每個攔截器中的代碼的執(zhí)行順序，在Action之前，攔截器的執(zhí)行順序與堆棧中定義的一致；而在Action和Result之后，攔截器的執(zhí)行順序與堆棧中定義的順序相反。