Spring IOC理論推導:
IOC理論推導：
以前方式(使用IOC之前)：
1.UserDao(接口)：
2：UserDaoImpl(實現類)：
3：UserService(業務接口)：
4：UserServiceImpl(業務實現類)：
5：MyTest(測試類)：
如果此時我們還需要一個需求。那麼首先需要編寫一個新的用戶實現類：UserDaoMsqlImpl
然後修改UserServiceImpl(服務實現類)中的對象：
如果此時又來一個新需求(UserDaoOracleImpl)
那麼我們又要去UserServiceImple中手動的修改對象：
如果此時我們又要使用SqlServer，又需要去UserServiceImpl裏面修改相應的實現(UserService userService = new UserSqlserverImpl()),假設我們的這種需求非常大，這種方式根本不適用，甚至反人類。每次變動，都需要修改大量代碼，這種設計的耦合性太高，牽一髮而動全身。
在以上這種業務中，用戶的需求可能會影響我們原來的代碼，我們需要根據用戶的需求取修改原來的代碼！如果程序代碼量十分大，修改一次的成本代價十分昂貴！
IOC方式：
爲了避免每當出現新需求，我們都要去手動修改對象。我們可以在UserServiceImpl(服務實現類)設置一個接口(之前都是通過new來創建對象)。然後通過set方法動態實現值的注入！
此時程序的主動權在用戶手上，用戶想調用哪個只需在setUserDao中放入所需的需求(Oracle就new UserDaoOracleImp).
之前程序是主動創建對象！控制權在程序員手上！
使用了set注入後，程序不在具有主動性。而是變成了被動的接受對象！
這種思想從本質上解決了問題，我們程序員不用再去管理對象的創建。系統的耦合性大大降低，可以更加專注的在業務的實現上！這是IOC的原型！
IOC本質：
控制反轉IOC(Inversion of Control),是一種設計思想，DI(依賴注入)是實現IOC的一種方法，也有人認爲DI只是IOC的另一種說法，在IOC的程序中，我們使用面向對象編程，對象的創建與對象之間的依賴關係完全硬編碼在程序中，對象的創建由程序自己控制；控制反轉後將對象的創建轉移給第三方，個人認爲所謂控制反轉就是：獲得依賴對象的方式反轉了。
控制反轉是一種通過描述(XML或註解)並通過第三方生產或獲取特定對象的方式。在Spring中實現控制反轉的是IOC容器，其實現方法是依賴注入。
IOC是Spring框架的核心內容，使用多種方式完美的實現了IOC，可以使用XML配置，也可以使用註解，新版本的Spring也可以實現零配置(自動裝配)實現IOC。
採用XML方式配置bean的時候，bean的定義信息是和實現分離的，而採用註解的方式可以把兩者合爲一體，bean的定義信息直接以註解的方式定義在實現類中，從而達到了零配置的目的。
spring容器在初始化的時候先讀取配置文件，根據配置文件或元數據創建與組織對象存入容器中，程序使用時再從IOC容器中取出需要的對象。
