圖解Spring2.5.6中面向切面編程(AOP)及實現(xiàn)分析
面向切面編程(AOP)通過提供另外一種思考程序結(jié)構(gòu)的途經(jīng)來彌補面向?qū)ο缶幊?OOP)的不足。在OOP中模塊化的關(guān)鍵單元是類(classes)，而在AOP中模塊化的單元則是切面。切面能對關(guān)注點進行模塊化，例如橫切多個類型和對象的事務(wù)管理。(在AOP術(shù)語中通常稱作橫切(crosscutting)關(guān)注點。)AOP框架是Spring的一個重要組成部分。但是Spring IoC容器并不依賴于AOP，這意味著你有權(quán)利選擇是否使用AOP，AOP做為Spring IoC容器的一個補充,使它成為一個強大的中間件解決方案。
AOP在Spring Framework中的作用提供聲明式企業(yè)服務(wù)，特別是為了替代EJB聲明式服務(wù)。最重要的服務(wù)是聲明性事務(wù)管理。允許用戶實現(xiàn)自定義切面，用AOP來完善OOP的使用。在業(yè)務(wù)系統(tǒng)中，總會在一些與業(yè)務(wù)邏輯無關(guān)服務(wù)邏輯(如:日志記錄，安全驗證，事物管理等)。
在傳統(tǒng)的編程方式中，這些服務(wù)邏輯的代碼總是會滲透到業(yè)務(wù)邏輯的代碼中，使得服務(wù)邏輯和業(yè)務(wù)邏輯完成完全混雜在一起，這樣會使業(yè)務(wù)系統(tǒng)變的更加復(fù)雜，根本不適用于當前大型業(yè)務(wù)系統(tǒng)的開打。如圖：
圖為：傳統(tǒng)編程方式下服務(wù)邏輯與業(yè)務(wù)邏輯交織
引入AOP后，把這些服務(wù)邏輯收集起來，設(shè)計成各個獨立可重用的切面，在需要該服務(wù)的業(yè)務(wù)邏輯之上織如即可。這樣，這些服務(wù)邏輯就靈活地應(yīng)用到業(yè)務(wù)系統(tǒng)中，在調(diào)用業(yè)務(wù)邏輯代碼時并不關(guān)心他們的存在。如圖。
圖為：引入AOP后服務(wù)邏輯和業(yè)務(wù)邏輯分離
要理解AOP，必須先理解好AOP的一下幾個術(shù)語：
l 切面(Aspect)：
一個關(guān)注點的模塊化，這個關(guān)注點可能會橫切多個對象。事務(wù)管理是J2EE應(yīng)用中一個關(guān)于橫切關(guān)注點的很好的例子。在Spring AOP中，切面可以使用基于模式)或者基于@Aspect注解的方式來實現(xiàn)。
l 連接點(Joinpoint)：
在程序執(zhí)行過程中某個特定的點，比如某方法調(diào)用的時候或者處理異常的時候。在Spring AOP中，一個連接點總是表示一個方法的執(zhí)行。
l 通知(Advice)：
在切面的某個特定的連接點上執(zhí)行的動作。其中包括了“around”、“before”和“after”等不同類型的通知(通知的類型將在后面部分進行討論)。許多AOP框架(包括Spring)都是以攔截器做通知模型，并維護一個以連接點為中心的攔截器鏈。
l 切入點(Pointcut)：
匹配連接點的斷言。通知和一個切入點表達式關(guān)聯(lián)，并在滿足這個切入點的連接點上運行(例如，當執(zhí)行某個特定名稱的方法時)。切入點表達式如何和連接點匹配是AOP的核心：Spring缺省使用AspectJ切入點語法。
l 引入(Introduction)：
用來給一個類型聲明額外的方法或?qū)傩?也被稱為連接類型聲明(inter-type declaration))。Spring允許引入新的接口(以及一個對應(yīng)的實現(xiàn))到任何被代理的對象。例如，你可以使用引入來使一個bean實現(xiàn)IsModified接口，以便簡化緩存機制。
l 目標對象(Target Object)：
被一個或者多個切面所通知的對象。也被稱做被通知(advised)對象。 既然Spring AOP是通過運行時代理實現(xiàn)的，這個對象永遠是一個被代理(proxied)對象。
l AOP代理(AOP Proxy)：
AOP框架創(chuàng)建的對象，用來實現(xiàn)切面契約(例如通知方法執(zhí)行等等)。在Spring中，AOP代理可以是JDK動態(tài)代理或者CGLIB代理。
l 織入(Weaving)：
把切面連接到其它的應(yīng)用程序類型或者對象上，并創(chuàng)建一個被通知的對象。這些可以在編譯時(例如使用AspectJ編譯器)，類加載時和運行時完成。Spring和其他純Java AOP框架一樣，在運行時完成織入。
聲明：
通知類型：
前置通知(Before advice)：在某連接點之前執(zhí)行的通知，但這個通知不能阻止連接點之前的執(zhí)行流程(除非它拋出一個異常)。
后置通知(After returning advice)：在某連接點正常完成后執(zhí)行的通知：例如，一個方法沒有拋出任何異常，正常返回。
異常通知(After throwing advice)：在方法拋出異常退出時執(zhí)行的通知。
最終通知(After (finally) advice)：當某連接點退出的時候執(zhí)行的通知(不論是正常返回還是異常退出)。
環(huán)繞通知(Around Advice)：包圍一個連接點的通知，如方法調(diào)用。這是***大的一種通知類型。環(huán)繞通知可以在方法調(diào)用前后完成自定義的行為。它也會選擇是否繼續(xù)執(zhí)行連接點或直接返回它自己的返回值或拋出異常來結(jié)束執(zhí)行。
通過切入點匹配連接點的概念是AOP的關(guān)鍵，這使得AOP不同于其它僅僅提供攔截功能的舊技術(shù)。 切入點使得通知可以獨立對應(yīng)到面向?qū)ο蟮膶哟谓Y(jié)構(gòu)中。例如，一個提供聲明式事務(wù)管理 的環(huán)繞通知可以被應(yīng)用到一組橫跨多個對象的方法上(例如服務(wù)層的所有業(yè)務(wù)操作)。
Spring AOP 實現(xiàn)
在Spring2.5.6中，常用的AOP實現(xiàn)的兩種方法：
***種，是基于xml配置文件方式的實現(xiàn)。
第二種，是基于注解方式實現(xiàn)的。
那么Spring AOP中使用@AspectJ(注解)還是XML?他們沒有沒有個子的優(yōu)缺點?
如果你不是運行 在Java 5上，XML風格是***選擇。對于使用Java 5的項目，需要考慮多方面的折衷。
XML風格對現(xiàn)有的Spring用戶來說更加習慣。它可以使用在任何Java級別中 (參考連接點表達式內(nèi)部的命名連接點，雖然它也需要Java 5+) 并且通過純粹的POJO來支持。當使用AOP作為工具來配置企業(yè)服務(wù)時XML會是一個很好的選擇。 (一個好的例子是當你認為連接點表達式是你的配置中的一部分時，你可能想單獨更改它) 對于XML風格，從你的配置中可以清晰的表明在系統(tǒng)中存在那些切面。
XML風格有兩個缺點。
***是 它不能完全將需求實現(xiàn)的地方封裝到一個位置。 DRY原則中說系統(tǒng)中的每一項知識都必須具有單一、無歧義、權(quán)威的表示。 當使用XML風格時，如何實現(xiàn)一個需求的知識被分割到支撐類的聲明中以及XML配置文件中。 當使用@AspectJ風格時就只有一個單獨的模塊 -切面- 信息被封裝了起來。
第二是 XML風格同@AspectJ風格所能表達的內(nèi)容相比有更多的限制：僅僅支持"singleton"切面實例模型， 并且不能在XML中組合命名連接點的聲明。例如，在@AspectJ風格中我們可以編寫如下的內(nèi)容：
Xml代碼
- @Pointcut(execution(* get*()))
- public void propertyAccess() {}
- @Pointcut(execution(org.xyz.Account+ *(..))
- public void operationReturningAnAccount() {}
- @Pointcut(propertyAccess() && operationReturningAnAccount())
- public void accountPropertyAccess() {}
在XML風格中能聲明開頭的兩個連接點：
Xml代碼
expression="execution(org.xyz.Account+ *(..))"/>
expression="execution(org.xyz.Account+ *(..))"/>
但是不能通過組合這些來定義accountPropertyAccess連接點
@AspectJ風格支持其它的實例模型以及更豐富的連接點組合。它具有將切面保持為一個模塊單元的優(yōu)點。 還有一個優(yōu)點就是@AspectJ切面能被Spring AOP和AspectJ兩者都理解 - 所以如果稍后你認為你需要AspectJ的能力去實現(xiàn)附加的需求，那么你非常容易遷移到基于AspectJ的途徑。 總而言之，我們更喜歡@AspectJ風格只要你有切面去做超出簡單的“配置”企業(yè)服務(wù)之外的事情。
結(jié)束語
我們完全可以混合使用以下幾種風格的切面定義：使用自動代理的@AspectJ風格的切面， schema-defined
【編輯推薦】
