深入理解Spring IOC
為什麽會出現spring，spring出現解決了什麽問題?
1.分析普通多層架構存在的問題
JSP->Servlet->Service->Dao
- 層與層之間的依賴很強，屬於耦合而且是緊耦合，各層對象的生命周期是由上層控制，下層定義或實現的改動都會影響到上層，需求變更時代碼改變多；
- 通常我們平時都是直接new的，對象生產機制效率較低；
2.使用Spring解決緊耦合問題（對象托管）
Spring通過IOC（控制反轉）機制和DI（依賴註入）機制將各層之間的（依賴）關系打散。
控制反轉：就是由容器(Spring)控制程序之間的（依賴）關系，而非傳統實現中，由程序代碼直接操控。
依賴註入：組件之間的依賴關系由容器在運行期決定，由容器動態的將某種依賴關系註入到組件之中。
（1）Spring（容器）控制所有對象的生命周期，上層不再控制下層的生命周期，層與層之間實現了完全脫耦，使程序運行起來效率更高，維護起來也方便；
（2）對象的創建方式也由Spring控制，默認是單例，效率比起每次new要高；
（3）IOC就是依賴控制轉化，利用JAVA的反射機制，將實例的初始化交給Spring。Spring可以通過配置文件管理實例。
3.Spring和簡單工廠設計模式有什麽不一樣？
Spring和簡單工廠都實現了控制反轉，也就是管理實例的初始化，在需要用該對象的時候，直接從外部申請而獲得該對象。下面分析2者的區別
簡單工廠模型
- 首先構建工廠類
該工廠可以生產蘋果和橙子2種對象
- 然後就是蘋果和橙子類和水果接口（為什麽需要接口：面向接口來強調的就是我們操縱的都是一些接口，所以我們永遠不會依賴於實現）
- 在測試類中調用
不難發現，其實簡單工廠模型和Spring非常相似，都是把對象的創建交給外部實現層解耦，但是當我們深入一層去思考一下問題，當我要在測試類要創建一個西瓜對象的時候，我們首先要加一個西瓜類然後繼承水果接口吧，然後呢，第二步就是在工廠類裏邊加入一段if(是西瓜) else{創建西瓜類} 判斷代碼是這樣吧。來到這裏簡單工廠模型的弊端就顯現出來了，簡單來說就是不能做到只是拓展就可以實現想要的，而是要修改代碼比如修改工廠類。如果我們添加太多的子類的時候，改動就會很多。
- 那麽Spring是怎麽處理的呢？
還是上邊的例子，水果類和水果類接口就不說了是一樣的如圖
- 關鍵在於工廠類
現在就算我們添加任意多個子類的時候，工廠類都不需要修改。Spring使用反射機制實現的工廠模式可以通過反射取得接口的實例，但是需要傳入完整的包和類名。而且用戶也無法知道一個接口有多少個可以使用的子類，所以我們通過屬性文件的形式配置所需要的子類。初始化的時候能夠掃描所有類路徑和包名
IOC原理小結
- IOC中最基本的技術就是反射，通俗來講就是根據給出的類名來動態地生成對象，這種編程方式可以讓對象在生成時才被決定到底是哪一種對象。我們可以把IOC容器的工作模式看做是工廠模式的升華，可以把IOC容器看作是一個工廠，這個工廠裏要生產的對象都在配置文件中給出定義，然後利用編程語言提供的反射機制，根據配置文件中給出的類名生成相應的對象。從實現來看，IOC是把以前在工廠方法裏寫死的對象生成代碼，改變為由配置文件來定義，也就是把工廠和對象生成這兩者獨立分隔開來，目的就是提高拓展性和可維護性。
- Spring的基本使用
- 把需要托管給spring的類註冊到配置文件中 以bean發布；
- 在需要用到的地方，以getBean的方式（可提供一個BeanUtil工具類），向spring容器獲取對應對象；
- 若要以依賴註入的方式，先要在配置文件中進行註入，然後在被註入的類中寫註入類的setter；、
- 使用註解（需在XML 配置文件中啟動 Spring 的自動掃描功能）
Spring 2.5 在 @Repository的基礎上增加了功能類似的額外三個註解：@Component、@Service、@Constroller，它們分別用於軟件系統的不同層次：
- @Component 是一個泛化的概念，僅僅表示一個組件 (Bean) ，可以作用在任何層次。
- @Service 通常作用在業務層，但是目前該功能與 @Component 相同。
- @Constroller 通常作用在控制層，但是目前該功能與 @Component 相同。
深入理解Spring IOC