AOP是一個什么概念呢？
AOP是Aspect Oriented Programming的縮寫，翻譯成中文就是面向方面編程。它是最近幾年流行起來的另一種編程方式。
- 首先，AOP只是OOP的補充，換句話說，Procedure Oriented Programming的工程是很難，也是幾乎不可能使用AOP的。
- 其次，AOP是對OOP系統的縱向切割，從另一個方面上實現了系統解耦
- 再次，AOP給OOP提供了另一種重用的可能。
對于OOP系統而言，系統的解耦主要依賴分層和良好的設計，一般良好的OOP架構沒有不采用分層和設計模式的（當然，分層分得恰當不恰當、模式用得好不好，跟框架的設計者有著直接的關系）。但是，對于OOP系統而言，它只能到達這一步了。
對于系統的必須要求，比如日志、錯誤跟蹤、訪問攔截、權限控制等操作，OOP就很難達到八面玲瓏。
其實，倒不是OOP一定不能實現上述功能的分離和重用，但是由于那又需要更高層次的抽象和封裝，憑空增加系統的復雜性和使用難度，又不利于版本控制和發布控制，一般來說，是得不償失的。
所以，很多開源項目比如Commons Logging等應運而生，它們的存在從一定的意義上解決了這個問題。
但是，還有一種很好的解決方案，那就是AOP（實際上AOP就是為了解決這種問題而誕生的）。
AOP既然是OOP系統的縱向切割，那么它就應該具備以下幾點：
- 切入點（Point Cut）：它需要一個點來切入到OOP系統中去，目前流行的AOP框架都采用從方法切入的方式。
- 切面（Advice）：切入之后，它要做些什么呢？必須可以有一種方式進行定制，目前流行的AOP框架都采用Java代碼實現的方式
- 重用性：一般來說，AOP能帶來的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，這就提供了一種可能，所有的Advice都可以通過打包成Jar的形式實現重用。
由此可以看出，使用AOP能夠帶來的好處是提供了一種抽象模型的方式、一種重用以前工作的方式（在不更改過去的代碼的基礎上添加新的功能、同時也可以重用過去寫的Advice）。
AOP還有一個好處，就是減少工作量。
因為目前流行的AOP框架的PointCut定義一般都支持通配，這樣就可以實現批量定義和修改。如果代碼有著良好的規范、在良好的設計下，開發和維護工作量的減少會非常可觀。而且對于添加新的功能不必修改原有的架構設計，從另一方面也降低了非常可觀的工作量。
那么AOP在JavaEE企業級應用中能夠起什么作用呢？
- 事務控制：很多業務邏輯方法都需要事務控制，通過通配實現事務控制絕對是一個節省工作量的好辦法，如果再結合IOC更加可以脫離事務控制的依賴，實現事務控制靈活更換，提高了業務系統的重用性
- 權限控制：權限控制到底算不算業務邏輯？如果不算，為什么還要體現在業務邏輯中？通過AOP的方式，可以靈活的實現FilterChain機制，而業務邏輯的代碼可以對其毫無察覺。
- 持久層對象的裝飾和過濾：可以根據需要對持久層操作返回的結果進行裝飾和過濾，甚至替換，而對系統架構沒有任何要求。這是最漂亮和最干凈的做法。
- 系統級別診斷日志：實現可插拔式系統級別日志，這樣在系統正常運行后就可以為了提高系統性能而不費事的去掉它卻不會影響到系統的穩定。
- 業務級別高級抽象：比如可以把工作流支持API封裝，通過AOP的機制實現Mixin，這樣就可以實現工作流支持和原業務邏輯分離，可以分開進行管理，也可以在更高的抽象級別上實現重用。
AOP也不是沒有缺點，它本身就有一定的學習曲線，而且目前為止有具體意愿的好的實踐并不多，而且它也會給你的工程帶來復雜性，它還會給你的代碼增加理解的難度（不管你承認不承認，代碼閱讀的難度確實是跟代碼的耦合程度反相關的——雖然這是設計模式所力圖解決的問題）
但是，目前來看適當的使用AOP，給你的項目提高靈活性和可維護性，是值得的。