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 是最佳選擇。然而,我們的經驗表明,對於企業 Java 應用中適合使用 AOP 的大多數問題,Spring AOP 提供了出色的解決方案。

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 Framework 的核心原則之一是非侵入性。這意味著您不應被迫將特定於框架的類和介面引入到您的業務或領域模型中。然而,在某些地方,Spring Framework 確實提供了將特定於 Spring Framework 的依賴項引入程式碼庫的選項。提供這些選項的理由是,在某些場景下,以這種方式閱讀或編寫某些特定功能可能更容易。然而,Spring Framework(幾乎)總是為您提供選擇:您可以自由地做出明智的決定,選擇最適合您的特定用例或場景的選項。

與本章相關的一個選擇是選擇哪種 AOP 框架(以及哪種 AOP 風格)。您可以選擇 AspectJ、Spring AOP 或兩者。您還可以選擇 @AspectJ 註解風格方法或 Spring XML 配置風格方法。本章選擇首先介紹 @AspectJ 風格方法,這不應被視為 Spring 團隊偏愛 @AspectJ 註解風格方法而非 Spring XML 配置風格方法的跡象。

有關每種風格的優缺點的更完整討論,請參閱 選擇使用哪種 AOP 宣告風格