最近剛買了一本介紹ssm框架的書，里面主要對Mybatis、spring、springmvc和redis做了很多的講解，個人覺得雖然有的內容我看不懂，但是整體上還是不錯的。最近正在學習中，一邊學習一邊做一些總結，現在我對這些思想技術還沒有達到很深入的理解，所以總結的比較淺顯。現在就把有關spring IOC的知識總結一下：

1.理解IOC和依賴注入

IOC，就是控制反轉：是一種通過描述并通過第三方去產生或獲取特定對象的方式。剛開始聽到這個名詞的時候，感覺很難理解，隨著逐漸熟悉，可以簡單的理解為，創建對象不需要通過new，而是交給spring容器，那spring容器創建對象并交給你使用的過程叫依賴注入。也就是說spring容器創建對象是通過依賴注入來完成的。

2.依賴注入的三種方式

既然spring創建對象是通過依賴注入來完成的，那就要講到依賴注入的三種方式了。一般來說，依賴注入可以分為三種方式。

• 構造器注入。
• setter注入。
• 接口注入。

構造器和setter注入是主要的方式，接口注入是從別的地方注入的方式。

2.1 構造器注入

原理：構造器注入是依賴于構造方法來實現的，大多數的情況下，我們是通過類的構造器來創建對象的，spring是通過反射的方式，通過構造器來完成注入。在配置文件中添加以下配置信息。
代碼如下：

<bean id="" class=""><constructor-arg index="" value="" /><constructor-arg index="" value="" />
</bean>

constructor-arg元素是用于定義類構造方法的參數，index是定義參數的位置，value則是設置參數的值，通過這樣的定義spring便知道使用什么樣的構造方法去創建對象了。
這樣的注入方式比較簡單，但是缺點就是如果構造方法的參數非常多，那么這樣的構造方法就會變得復雜，可讀性也會得差，所以要考慮其它的方式。

2.2 setter注入

setter注入是spring中最主流的注入方式，它利用java bean規范所定義的setter方法來完成注入，靈活且可讀性也高。就是消除了構造器注入時出現過多參數的問題，首先把構造器聲明為無參的，然后通過setter注入為其設置對應的值，其實也是通過反射技術實現的，
配置信息如下：

<bean id="" class=""><property  name="" value="" /><property  name="" value="" />
</bean>

通過這樣的配置spring就會通過反射調用無參構造器生成對象，同時通過反射對應的setter注入配置值了。這種方式是spring最為主要的方式。

2.3 接口注入

這個方式好像不是很常用，所以這里就不做總結了，只是簡單的了解一下。

小結

以上是對我學習的一些總結，內容不是很專業，所以下面引用其他大神們的講解

看大神的講解

下面內容來自：http://jinnianshilongnian.iteye.com/blog/1413846

3.1.1 IoC是什么

Ioc—Inversion of Control，即“控制反轉”，不是什么技術，而是一種設計思想。在Java開發中，Ioc意味著將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確“誰控制誰，控制什么，為何是反轉（有反轉就應該有正轉了），哪些方面反轉了”，那我們來深入分析一下：

• 誰控制誰，控制什么：傳統Java SE程序設計，我們直接在對象內部通過new進行創建對象，是程序主動去創建依賴對象；而IoC是有專門一個容器來創建這些對象，即由Ioc容器來控制對象的創建；誰控制誰？當然是IoC 容器控制了對象；控制什么？那就是主要控制了外部資源獲取（不只是對象包括比如文件等）。

• 為何是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙創建及注入依賴對象；為何是反轉？因為由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。

用圖例說明一下，傳統程序設計如圖3-1，都是主動去創建相關對象然后再組合起來：

圖3-1 傳統應用程序示意圖

當有了IoC/DI的容器后，在客戶端類中不再主動去創建這些對象了，如圖3-2所示:

圖3-2有IoC/DI容器后程序結構示意圖

3.1.2 IoC能做什么

IoC不是一種技術，只是一種思想，一個重要的面向對象編程的法則，它能指導我們如何設計出松耦合、更優良的程序。傳統應用程序都是由我們在類內部主動創建依賴對象，從而導致類與類之間高耦合，難于測試；有了IoC容器后，把創建和查找依賴對象的控制權交給了容器，由容器進行注入組合對象，所以對象與對象之間是松散耦合，這樣也方便測試，利于功能復用，更重要的是使得程序的整個體系結構變得非常靈活。

其實IoC對編程帶來的最大改變不是從代碼上，而是從思想上，發生了“主從換位”的變化。應用程序原本是老大，要獲取什么資源都是主動出擊，但是在IoC/DI思想中，應用程序就變成被動的了，被動的等待IoC容器來創建并注入它所需要的資源了。

IoC很好的體現了面向對象設計法則之一—— 好萊塢法則：“別找我們，我們找你”；即由IoC容器幫對象找相應的依賴對象并注入，而不是由對象主動去找。

3.1.3 IoC和DI

DI—Dependency Injection，即“依賴注入”：是組件之間依賴關系由容器在運行期決定，形象的說，即由容器動態的將某個依賴關系注入到組件之中。依賴注入的目的并非為軟件系統帶來更多功能，而是為了提升組件重用的頻率，并為系統搭建一個靈活、可擴展的平臺。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業務邏輯，而不需要關心具體的資源來自何處，由誰實現。

理解DI的關鍵是：“誰依賴誰，為什么需要依賴，誰注入誰，注入了什么”，那我們來深入分析一下：

• 誰依賴于誰：當然是應用程序依賴于IoC容器；

• 為什么需要依賴：應用程序需要IoC容器來提供對象需要的外部資源；

• 誰注入誰：很明顯是IoC容器注入應用程序某個對象，應用程序依賴的對象；

• 注入了什么：就是注入某個對象所需要的外部資源（包括對象、資源、常量數據）。

IoC和DI由什么關系呢？其實它們是同一個概念的不同角度描述，由于控制反轉概念比較含糊（可能只是理解為容器控制對象這一個層面，很難讓人想到誰來維護對象關系），所以2004年大師級人物Martin Fowler又給出了一個新的名字：“依賴注入”，相對IoC 而言，“依賴注入”明確描述了“被注入對象依賴IoC容器配置依賴對象”

轉載于:https://www.cnblogs.com/black-spike/p/7648164.html

總結

以上是生活随笔為你收集整理的Spring学习－理解IOC和依赖注入的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。