Spring AOP是用純的java實現的。不須要任何個性的實現過程。Spring AOP不須要控制類加載器,而且它適用於Servlet容器或者應用服務器。java
Spring AOP當前只支持方法執行的鏈接點(通知Spring beans的方法執行)。字段的攔截沒有實現,雖然支持字段的攔截,能夠在不破壞核心Spring AOP API的狀況下添加。若是你須要通知字段獲取和根性鏈接點,能夠考慮一種相似AspectJ的語言。服務器
用Spring AOP的方式實現AOP不一樣於大多數其餘的AOP框架。它的目標不是提供一種最完整的AOP實現(雖然Spring AOP已經很是的強大);它更傾向於在AOP實現和Spring IoC之間提供一種封閉的整合,從而幫補解決企業應用中的哪些通用的問題。框架
例如,Spring框架的AOP功能一般與Spring Ioc容器結合使用。Aspects使用通用的bean 定義的語法來配置(雖然它容許強大的自動代理的方式):與其餘的AOP實現相比,這是一個很重要的不一樣點。有些事情若是你不使用Spring AOP,將很難或者不能高效的去作,例如通知細粒度的對象(如典型的業務對象):而在這種狀況下AspectJ是最好的選擇。然而,咱們的經驗是,Spring AOP爲企業級Java應用中大多數問題提供了一個優秀的解決方案,這些問題在AOP中很容易控制。編碼
Spring AOP歷來沒有爲與AspectJ競爭提供一個綜合的AOP而糾結。咱們相信這樣兩種基於代理的框架如Spring AOP和成熟的AspectJ都是有存在價值的,而且他們是相互補充的,而不是相互競爭的關係。Spring 2.0將Spring AOP和IoC與AspectJ無縫整合,從而是AOP的所有使用在一系列的基於Spring的應用框架中適應能力更強。這個整合沒有影響到Spring AOP的API或者AOP Alliance API:Spring AOP保持着向後兼容。.net
Spring框架的一個核心原則就是非侵入性;這就是說你不會被強制引入框架的個性類和接口到你本身的業務領域模型。然而在Spring框架的一些地方給了你引入Spring框架特性的依賴到你的代碼中:給你這些東西的緣由是,在一些特定的場景,以這種方式編碼可能更加的可讀性.Spring框架大多數狀況下給你一些選擇,這樣你就能夠自由的作一個合理的決定,用來適應一些特定的狀況和場景。代理
你須要選擇使用AspectJ仍是Spring AOP或者兩者都用,並且你也要選擇使用@AspectJ註解方式或者Spring Xml配置風格的方式。對象
-----------------------------------blog
轉自:https://blog.csdn.net/oFengFengFeng/article/details/52131460接口