一、概述

spring 的ioc解決的是物件之間的依賴的問題。spring 的aop解決的是業務邏輯和系統公用模組之間的解耦的問題。

他將系統公用的模組，比如事務處理、安全監聽、列印日誌等等模組，作為橫切關注點，在不破壞原有業務邏輯的前提下，插入業務邏輯層。這樣就相當於在業務邏輯層插入了一些公用模組的元件，來幫助我們監聽系統的執行情況。

在涉及到公共模組的修改的時候，不用在連線點附近一個一個修改，而是隻要修改公用的那個模組就可以了（即橫切關注點）。這樣就實現了橫切關注點和業務邏輯之間的解耦。

Spring預設使用JDK動態代理實現AOP代理。這使得任何介面或 介面的集合能夠被代理。Spring也可以是CGLIB代理。這可以代理類，而不是介面。

二、總結

（1）spring ioc

spring ioc是通過spring框架的封裝，實現了依賴的反轉，即：不是專案依賴於容器，而是容器為專案提供服務。

換句話說，原本傳統模式下，我們是先建立專案，然後手動的建立容器，容器裡面再注入各種各樣的實體類，塞滿容器。這樣做，我們會很累，因為當你的專案越來越大的時候，光是一個jdbc的容器，我們就要注入很多層。

反之，如果我們在專案啟動的時候，就先把這些需要使用到的容器，通過spring先完成依賴關係的注入，那麼我們在專案中，需要使用這些元件的時候，就可以直接使用了，就不用再一次一次的手動注入、生成這些元件了。

這也就是不是專案依賴於容器，而是容器為專案提供服務這句話的深層次含義。

（2）spring aop

spring aop做的事情，和spring ioc有相似之處。

他們兩個都實現了程式碼的解耦，ioc解耦了專案和容器之間的耦合。而aop解耦了核心業務邏輯層和輔助功能層（比如：事務處理、日誌列印、安全監控等等）之間的耦合。

spring ioc是完成組建的注入，讓我們在專案中可以直接使用，而不用一次次的手動注入，減少了我們的冗餘程式碼。

而spring aop的實現邏輯則不同：

假設專案的業務邏輯層已經完善，但是我們需要在A、B、C業務中加入不同的輔助功能（之所以叫做輔助功能，是因為這些功能是不影響業務邏輯的）比如，A業務是事務處理。B事務是安全監聽。C事務是日誌列印。

你可以看到A、B、C三個業務對於我們原本的核心業務邏輯是不產生任何影響的。

我們傳統的做法是，每次遇到A、B、C業務的時候，都自己去手寫，這樣當然是可以的。

但是，有沒有更好的方式？有，spring AOP就提供了這樣的解決辦法。

我們在spring aop 中，主要是基於動態代理，將業務邏輯的方法呼叫點做了分隔或者說打斷，打斷之後，我們可以在這個方法的呼叫點前後，加上自定義的方法。

這樣做的好處是在於：

1.打斷之後，我們可以將A、B、C三個業務模組寫到一個公共的地方，減少了冗餘程式碼，提升了程式碼的可維護性。

2.我們可以將打斷的所有點，稱為切入點，我們可以管理這些切入點。

3.我們可以對目標類進行引入（增加方法或欄位）。

4.將輔助功能和業務邏輯解耦，兩者非耦合，提升了程式碼的靈活度。

也就是說，當我需要將輔助層（比如：事務管理邏輯層、效能監視邏輯層）的功能做優化和改動的時候，不會涉及業務邏輯層的程式碼的修改，不會影響業務邏輯層的執行。

實際上，spring aop運用了代理，代理能夠將類和方法作為引數，通過其中封裝的方法來呼叫任意被代理類的任意方法（當然介面也可以被代理）。正因為代理的這個特性，使得spring aop具備了某種類似於打斷的功能：我只要把你這個類代理了，然後我在你呼叫前後，加上我的橫切關注點(輔助功能模組)就好了。