儘管用spring開發了一段時間，但僅僅使用了其ioc容器與mvc功能，對於aop與事務管理涉獵甚少。
今天看了一下aop方面的東西，其描述似乎確實能夠解決常見的幾個頭疼的問題：日誌記錄、錯誤處理、與許可權控制。這類問題稱之為crosscutting需求，是指在乙個程式中影響（橫切）其它關係的aspect（橫切其它核心關係的部分）。這些關係通常在設計和實現時都不能和系統的剩餘部分被清晰地分解出來，從而導致發散的、混亂的或者既發散又混亂的程式。
這個圖還是挺形象的。
三個服務courseservice、studentservice以及miscservice都屬於服務層，實現應用程式的業務邏輯，而這三個服務都需要安全控制、事務管理以及其他的共同需求等。這些需求與服務相依賴，但又橫穿所有的服務。
引用一下夏昕對oop與aop比較的描述：
oop（物件導向程式設計）針對業務處理過程的實體及其屬性和行為進行抽象封裝，以獲得更加清晰高效的邏輯單元劃分。而aop則是針對業務處理過程中的切面進行提取，它所面對的是處理過程中的某個步驟或階段，以獲得邏輯過程中各部分之間低耦合性的隔離效果。這兩種設計思想在目標上有著本質的差異。
舉個簡單的例子，對於「雇員」這樣乙個業務實體進行封裝，自然是oop/ood的任務，我們可以為其建立乙個「employee」類，並將「雇員」相關的屬性和行為封裝其中。而用aop設計思想對「雇員」進行封裝將無從談起。同樣，對於「許可權檢查」這一動作片斷進行劃分，則是aop的目標領域。而通過ood/oop對乙個動作進行封裝，則有點不倫不類。
換而言之，ood/oop面向名詞領域，aop面向動詞領域。
aop和ood/oop並不衝突，我們完全可以在乙個應用系統中同時應用ood/oop和aop設計思想，通過ood/oop對系統中的業務物件進行建模，同時通過aop對實體處理過程中的階段進行隔離處理。即使不是ood/oop，而是在傳統的pop（面向過程程式設計）中，aop也能起到同樣的作用。
看了幾個簡單的例子，對如何採用aop來實現crosscutting需求有了一定的了解，在呼叫所有符合指定要求的方法時，在適當的地方（方法之前，之後或丟擲異常時）加入指定的控制**，這段控制**是經過抽象了的，集中的，並能與呼叫方法完全分離。但甚為浮淺，遠遠不夠。比如對日誌處理而言，可以將很多本應分散在不同類中的操作資訊放在同乙個方法中進行，但如何保證不同操作對應的不同的記錄資訊呢？
看了一下自己沒有採用aop的解決過程。將spring的controller與******formcontroller的通用行為進行抽象後，許可權控制與錯誤處理都能夠集中在一起處理，即使沒有採用aop，但仍然能達到類似的效果，還算不錯，但日誌記錄卻完全分散個不同的類中，感覺有些亂，且不好控制，事務處理則完全沒有考慮，汗滴了。。。。
再看看吧，試了幾個例子再說。
spring aop入門 序列三
前兩部分了解了aop的 以及aop的基本術語，本節通過乙個簡單的例子來入門下aop。這裡通過乙個簡單的 效能評估 的例子來表述下 效能監控子方法 public class methodperformance public void printperformance 效能監控主方法 public cl...
Spring aop學習示例
我這裡只貼出來關鍵類和配置檔案。aspect類 spring配置檔案 xmlns xsi xmlns context xmlns aop xmlns tx xmlns mvc xsi schemalocation spring beans 3.2.xsd spring context 3.2.xsd...
spring aop學習記錄
aop 面向介面程式設計，也是面向多個物件程式設計。spring 5種通知 前置，後置，環繞，異常，引入通知。1.前置通知 繼承 org.springframework.aop.methodbeforeadvice 實現public void before method method,object ...