5.1。AOP概念

讓我們首先定義一些中心AOP概念和術語。這些術語不是特定于Spring的。不幸的是，AOP術語不是特別直觀。但是，如果Spring使用自己的術語，那將更加令人困惑。

• 方面：跨越多個類別的關注點的模塊化。事務管理是企業Java應用程序中橫切關注點的一個很好的例子。在Spring AOP中，方面是通過使用常規類（基于模式的方法）或使用@Aspect注釋（@AspectJ樣式）注釋的常規類來實現的?。

• 加入點：程序執行期間的一個點，例如執行方法或處理異常。在Spring AOP中，連接點始終表示方法執行。

• 建議：特定連接點的某個方面采取的操作。不同類型的建議包括“周圍”，“之前”和“之后”建議。（建議類型將在后面討論。）許多AOP框架（包括Spring）將建議建模為攔截器并在連接點周圍維護一系列攔截器。

• 切入點：匹配連接點的謂詞。建議與切入點表達式相關聯，并在切入點匹配的任何連接點處運行（例如，執行具有特定名稱的方法）。由切入點表達式匹配的連接點的概念是AOP的核心，Spring默認使用AspectJ切入點表達式語言。

• 簡介：代表類型聲明其他方法或字段。Spring AOP允許您向任何建議的對象引入新接口（以及相應的實現）。例如，您可以使用簡介使bean實現?IsModified接口，以簡化緩存。（介紹被稱為AspectJ社區中的類型間聲明。）

• 目標對象：由一個或多個方面建議的對象。也稱為“建議對象”。由于Spring AOP是使用運行時代理實現的，因此該對象始終是代理對象。

• AOP代理：由AOP框架創建的對象，用于實現方面契約（建議方法執行等）。在Spring Framework中，AOP代理是JDK動態代理或CGLIB代理。

• 編織：將方面與其他應用程序類型或對象鏈接以創建建議對象。這可以在編譯時（例如，使用AspectJ編譯器），加載時間或在運行時完成。與其他純Java AOP框架一樣，Spring AOP在運行時執行編織。

Spring AOP包括以下類型的建議：

• 建議之前：在連接點之前運行但無法阻止執行流程進入連接點的建議（除非它拋出異常）。

• 返回建議后：在連接點正常完成后運行的建議（例如，如果方法返回而不拋出異常）。

• 拋出建議后：如果方法通過拋出異常退出，則執行建議。

• 在（最終）建議之后：無論連接點退出的方式（正常或異常返回），都要執行建議。

• 圍繞建議：圍繞連接點的建議，例如方法調用。這是最有力的建議。around通知可以在方法調用之前和之后執行自定義行為。它還負責選擇是繼續加入點還是通過返回自己的返回值或拋出異常來快速建議的方法執行。

圍繞建議是最普遍的建議。由于Spring AOP（如AspectJ）提供了全方位的建議類型，因此我們建議您使用可以實現所需行為的最不強大的建議類型。例如，如果您只需要使用方法的返回值更新緩存，那么最好實現返回后的建議而不是周圍的建議，盡管周圍的建議可以完成同樣的事情。使用最具體的建議類型可以提供更簡單的編程模型，減少錯誤的可能性。例如，您不需要proceed()?在JoinPointused for around advice?上調用該方法，因此，您無法調用它。

所有通知參數都是靜態類型的，因此您可以使用相應類型的通知參數（例如，方法執行的返回值的類型）而不是Object數組。

由切入點匹配的連接點的概念是AOP的關鍵，它將其與僅提供攔截的舊技術區分開來。切入點使得建議可以獨立于面向對象的層次結構進行定向。例如，您可以將一個提供聲明性事務管理的建議應用于跨多個對象的一組方法（例如服務層中的所有業務操作）。

5.2。Spring AOP功能和目標

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

Spring AOP目前僅支持方法執行連接點（建議在Spring bean上執行方法）。雖然可以在不破壞核心Spring AOP API的情況下添加對字段攔截的支持，但未實現字段攔截。如果您需要建議字段訪問和更新連接點，請考慮使用AspectJ等語言。

Spring AOP的AOP方法與大多數其他AOP框架的方法不同。目的不是提供最完整的AOP實現（盡管Spring AOP非常強大）。相反，目標是在AOP實現和Spring IoC之間提供緊密集成，以幫助解決企業應用程序中的常見問題。

因此，例如，Spring Framework的AOP功能通常與Spring IoC容器一起使用。通過使用普通bean定義語法來配置方面（盡管這允許強大的“自動代理”功能）。這是與其他AOP實現的重要區別。使用Spring AOP無法輕松或高效地完成某些操作，例如建議非常細粒度的對象（通常是域對象）。在這種情況下，AspectJ是最佳選擇。但是，我們的經驗是Spring AOP為適合AOP的企業Java應用程序中的大多數問題提供了出色的解決方案。

Spring AOP從未努力與AspectJ競爭，以提供全面的AOP解決方案。我們認為，基于代理的框架（如Spring AOP）和完整的框架（如AspectJ）都很有價值，而且它們是互補的，而不是競爭。Spring將Spring AOP和IoC與AspectJ無縫集成，以在一致的基于Spring的應用程序架構中實現AOP的所有使用。此集成不會影響Spring AOP API或AOP Alliance API。Spring AOP仍然向后兼容。有關?Spring AOP API的討論，請參閱以下章節。

?

Spring框架的核心原則之一是非侵入性。這個想法是，您不應該被迫在您的業務或域模型中引入特定于框架的類和接口。但是，在某些地方，Spring Framework確實為您提供了將Spring Framework特定的依賴項引入代碼庫的選項。為您提供此類選項的基本原理是，在某些情況下，以這種方式閱讀或編寫某些特定功能可能更容易。但是，Spring Framework（幾乎）總是為您提供選擇：您可以自由決定哪種選項最適合您的特定用例或場景。 與本章相關的一個選擇是選擇哪種AOP框架（以及哪種AOP樣式）。您可以選擇AspectJ，Spring AOP或兩者。您還可以選擇@AspectJ注釋樣式方法或Spring XML配置樣式方法。本章選擇首先介紹@ AspectJ風格的方法，這一事實不應被視為Spring團隊傾向于采用Spring XML配置風格的@AspectJ注釋風格方法。 請參閱選擇要使用的AOP聲明樣式，以更全面地討論每種樣式的“為什么和為何”。

5.3。AOP代理

Spring AOP默認使用AOP代理的標準JDK動態代理。這使得任何接口（或接口集）都可以被代理。

Spring AOP也可以使用CGLIB代理。這是代理類而不是接口所必需的。默認情況下，如果業務對象未實現接口，則使用CGLIB。由于優化的做法是編程接口而不是類，業務類通常實現一個或多個業務接口。可以?強制使用CGLIB，在那些需要建議未在接口上聲明的方法或需要將代理對象作為具體類型傳遞給方法的情況下（希望很少見）。

掌握Spring AOP是基于代理的這一事實非常重要。請參閱?了解AOP代理，以全面了解此實現細節的實際含義。

5.4。@AspectJ支持

@AspectJ指的是將方面聲明為使用注釋注釋的常規Java類的樣式。作為AspectJ 5版本的一部分，AspectJ項目引入了@AspectJ樣式?。Spring使用AspectJ提供的庫解釋與AspectJ 5相同的注釋，用于切入點解析和匹配。但是，AOP運行時仍然是純Spring AOP，并且不依賴于AspectJ編譯器或weaver。

更加詳盡的springAOP參見官方文檔：https://docs.spring.io/spring/docs/5.1.6.RELEASE/spring-framework-reference/core.html#aop-introduction-spring-defn

轉載于:https://www.cnblogs.com/TomFord/p/10736262.html

總結

以上是生活随笔為你收集整理的Spring AOP Capability and goals的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。