介紹

　　面向切面編程（AOP）作為面向對象編程（OOP）的一種補充，提出了另一種程序結構的思考方式。OOP中模塊化的關鍵單元是類，而AOP模塊的單位是一個切面。切面實現了對關注點的模塊化，諸如貫穿于多種類型和對象的事務管理。（這種關注在AOP中通常被稱為橫切關注點）

　　SPRing的一個關鍵組件就是AOP框架。而Spring IoC容器沒有依賴于AOP，那就意味著如果你不想，你不需要使用AOP。AOP補充了Spring　IoC，提供了一個非常強大的中間件解決方案。

Spring框架中使用AOP

注意 如果您只對通用聲明式服務，或其他預先打包的聲明式中間件服務，如pooling感興趣，你不需要直接使用Spring AOP，并且可以跳過本章的大部分內容。

AOP概念

　　讓我們開始定義一些主要的AOP概念和術語。 這些術語不是Spring特有的，不幸的是，AOP術語不是特別直觀; 然而，如果Spring使用自己的術語，它會更多混亂。 - 切面（Aspect）——即貫穿多個類的模塊化關注點。事務管理是java企業應用程序中橫切關注的一個很好的例子。 在Spring AOP中，切面使用普通類（基于Schema的方法）或被@Aspect注解的普通類(@AspectJ風格)來實現。 - 連接點（Joinpoint）——程序執行過程中的一個點，如一個方法的執行或異常的處理。在Spring AOP中，一個連接點總是代表一個方法的執行。 - 通知（Advice）——在切面的某個特定連接點發生的動作。 不同類型的通知包括”around”，”before”和”after”（通知類型在下面討論）。許多AOP框架，包括Spring，把一個通知建模為攔截器，連接點周圍一般維持一系列的攔截器。 - 切入點（Point Cut）——匹配連接點的術語。通知和切入點表達式相關聯并且在任何匹配切入點的連接點運行。（例如，在特定的名稱處執行方法）。通過切入表達式匹配的連接點的概念是AOP的核心，Spring默認情況下使用AspectJ切入點表達式語言。 -引言（Introduction）——聲明代表一個類型的其他方法或字段。Spring AOP允許你向任何通知的對象引入新接口（和相應的實現）。例如，你可以使用引入來使一個bean實現 IsModified接口，以便簡化緩存。（在AspectJ社區，引言被稱為的類型間聲明。） - 目標對象（Target object）——被一個或多個切面通知的對象。 也被稱作被通知對象。因為Spring AOP是通過運行時代理實現的，這個對象永遠是一個被代理對象。 - AOP代理（AOP proxy）——以AOP框架創建的對象為了實現切面契約（通知方法執行等）。 在Spring框架中，AOP代理將是一個JDK動態代理或CGLIB代理。 - 編織（Weaving）——連接切面和其他應用程序類型或對象來創建一個被通知的對象。這個可以在編譯期間（使用AspectJ編譯器）、加載期間、或者運行期間完成。Spring AOP與其他純Java AOP框架一樣，在運行期執行織入。

通知類型：

環繞通知是最普通的一種通知。由于Spring AOP提供了像AspectJ一樣的全部范圍的通知類型，我們建議您在能實現要求功能的情況下，使用最簡化的通知類型。例如，如果你僅僅需要用方法的返回值更新緩存，你最好實現一個返回后通知而不是環繞通知，雖然環繞通知也能完成相同的功能。使用大多數特定的通知類型都能提供一個簡單的編程模型并且很少有潛在錯誤。例如，在環繞通知中，你不需要在JoinPoint上調用proceed()方法。因此，你不可能存在調用失敗。

在Spring 2.0中，所有通知參數都是靜態類型的，因此您可以使用適當類型（例如從方法執行的返回值的類型）的通知參數，而不是對象數組。連接點的概念是AOP的關鍵，它匹配切入點，區別于只提供攔截功能的老技術。 切入點使得通知能夠單獨定位面向對象層次結構。 例如，一個提供聲明性事務管理的環繞通知可以應用于跨越多個對象的一組方法（例如服務層中所有業務操作）。

Spring AOP的能力和目標

Spring AOP是純Java實現，不需要特殊的編譯過程。Spring AOP不需要控制類加載器的層次結構，因此它適用于Servlet容器中或者應用服務器。

Spring AOP目前僅支持方法執行連接點（在Spring Bean上通知方法的執行），雖然可以在不影響到Spring AOP核心API的情況下加入對成員變量攔截器的支持，但Spring并沒有實現成員變量攔截器。 如果你需要把對成員變量的訪問和更新也作為通知的連接點，可以考慮其它語言，例如AspectJ。

Spring AOP的AOP實現方式不同于其他大部分AOP框架。它的目的不是去提供最完整的AOP實現（盡管Spring AOP有這個能力），而是提供AOP實現和Spring IOC的緊密結合，來幫助解決企業應用中的常見問題。

因此，Spring框架的AOP功能通常都是和Spring IOC容器結合使用。切面的配置使用標準的bean語法定義（盡管允許使用強大的“autoproxying”功能），這是Spring AOP區別于其他AOP實現的關鍵不同。有些情況下，如細粒度對象的切面，使用Spring AOP并不一定簡單和高效。這種情況下使用AspectJ是最好的選擇。不過，經驗告訴我們，Spring是經得起考驗的AOP框架，在企業Java應用中的大多數問題它都能提供優秀的解決方案。

Spring AOP從來沒有打算通過提供一種全面的AOP解決方案來取代AspectJ。我們相信無論是像Spring這種基于代理的框架亦或是像AspectJ這種成熟的框架，都是很有價值的，并且，他們之間的關系更應該是互補而不是競爭的關系。Spring利用AspectJ無縫集成Spring AOP和IOC，使得所有的AOP應用完全融入基于Spring的應用體系。這種集成并不影響Spring AOP API或AOP聯盟API,Spring AOP保持向后兼容。

注意 Spring的一個核心原則就是非侵入性，也就是說你不應該在你的業務模型中強制引用框架特定的類或者接口,但是，在某些地方，Spring框架會給你選擇在你的代碼庫中引入Spring框架特定的依賴：提供這種選擇的理由是，在某些情況下它可能更容易閱讀或使代碼以某種特定的方式實現功能。 Spring框架幾乎一直給你提供一種選擇：你可以自己決定，以選擇適合你自己的特定場景。與本章相關的選擇正是AOP框架（AOP風格）的選擇。你可以選擇AspectJ和/或Spring AOP，你也可以選擇 @AspectJ注解方式或Spring xml配置文件的方式。這章中選擇首先介紹@AspectJ注解的方式，并不能表明Spring團隊更喜歡@Aspect注解方式而不是Spring XML配置的方式。關于如何選擇哪種方式請參看

AOP代理

Spring AOP 缺省使用標準的JDK動態代理作為AOP代理。任何接口（或接口組）都可以被代理。它也可以使用CGLIB代理。 對于需要代理類而不是代理接口的時候CGLIB代理是很有必要的。如果業務對象沒有實現接口，則默認使用CGLIB。此外，面向接口編程也是一個最佳實踐，業務對象通常都會實現一個或多個接口。此外，還可能會強制使用CGLIB，在這種（希望很少）情況下，你需要通知一個未在接口上聲明的方法，或者您需要傳遞代理對象的地方作為具體類型的方法。