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