IoC，
用白話來講，就是由容器控制程序之間的關系，而非傳統實現中，由程序代碼直接操控。這也就是所謂“控制反轉”的概念所在：控制權由應用代碼中轉到了外部容器，控制權的轉移，是所謂反轉。
DI，
依賴注入的幾種實現類型:
1.接口注入
2.構造子注入
3.設值注入
幾種依賴注入模式的對比總結
接口注入模式因為具備侵入性，它要求組件必須與特定的接口相關聯，因此并不被看好，實際使用有限。
Type2和Type3的依賴注入實現模式均具備無侵入性的特點。在筆者看來，這兩種實現方式各有特點，也各具優勢（一句經典廢話J）。
Type2 構造子注入的優勢：
1． “在構造期即創建一個完整、合法的對象”，對于這條Java設計原則，Type2無疑是最好的
響應者。
2． 避免了繁瑣的setter方法的編寫，所有依賴關系均在構造函數中設定，依賴關系集中呈現，
更加易讀。
3． 由于沒有setter方法，依賴關系在構造時由容器一次性設定，因此組件在被創建之后即處于相對“不變”的穩定狀態，無需擔心上層代碼在調用過程中執行setter方法對組件依賴關系產生破壞，特別是對于Singleton模式的組件而言，這可能對整個系統產生重大的影響。
4． 同樣，由于關聯關系僅在構造函數中表達，只有組件創建者需要關心組件內部的依賴關系。對調用者而言，組件中的依賴關系處于黑盒之中。對上層屏蔽不必要的信息，也為系統的層次清晰性提供了保證。
5． 通過構造子注入，意味著我們可以在構造函數中決定依賴關系的注入順序，對于一個大量依賴外部服務的組件而言，依賴關系的獲得順序可能非常重要，比如某個依賴關系注入的
先決條件是組件的DataSource及相關資源已經被設定。
Type3 設值注入的優勢
1． 對于習慣了傳統JavaBean開發的程序員而言，通過setter方法設定依賴關系顯得更加直
觀，更加自然。
2． 如果依賴關系（或繼承關系）較為復雜，那么Type2模式的構造函數也會相當龐大（我們需要在構造函數中設定所有依賴關系），此時Type3模式往往更為簡潔。
3． 對于某些第三方類庫而言，可能要求我們的組件必須提供一個默認的構造函數（如Struts
中的Action），此時Type2類型的依賴注入機制就體現出其局限性，難以完成我們期望的功
能。
注：本文的很多總結來源于對《spring框架，技術詳解及使用指導》（作者：夏昕）的學習。