Spring的IOC原理（通俗易懂）

Spring的IOC原理（通俗易懂）1.理論的背景我們都知道，在采??法設計的軟件系統(tǒng)中，它的底層實現都是由?個對象組成的，所有的對象通過彼此的合作，最終實現系統(tǒng)的業(yè)務邏輯。如果我們打開機械式?表的后蓋，就會看到與上?類似的情形，各個齒輪分別帶動時針，分針和秒針順時針旋轉，從?在表盤上產?正確的時間。圖1中描述的就是這樣的?個齒輪組，它擁有多個獨?的齒輪，這些齒輪相互嚙合在?起，協同?作，共同完成某項任務。我們可以看到，在這樣的齒輪組中，如果有?個齒輪出了問題，就可能會影響到整個齒輪組的正常運轉。齒輪組中齒輪之間的嚙合關系，與軟件系統(tǒng)中對象之間的耦合關系?常相似。對象之間的耦合關系是?法避免的，也是必要的，這是協同?作的基礎?，F在，伴隨著?業(yè)級應?的規(guī)模越來越龐?，對象之間的依賴關系也越來越復雜，經常會出現對象之間的多重依賴性關系，因此，架構師和設計師對于系統(tǒng)的分析和設計，將?臨更?的挑戰(zhàn)。對象之間耦合度過?的系統(tǒng)，必然會出現牽?發(fā)?動全?的情形。耦合關系不僅會出現在對象與對象之間，也會出現在軟件系統(tǒng)的各模塊之間，以及軟件系統(tǒng)和硬件系統(tǒng)之間。如何降低系統(tǒng)之間，模塊之間和對象之間的耦合度，是軟件?程永遠追求的?標之?。為了解決對象之間的耦合度過?的問題，軟件專家MichaelMattson提出了IOC理論，?來實現對象之間的“解耦”，?前這個理論已經被成功地應?到實踐當中，很多的J2EE項?均采?了國際奧委會產品Spring。2.什么是控制反轉（IoC）IOC是InversionofControl的縮寫，多數書籍翻譯成“控制反轉”，還有些書籍翻譯成為“控制反向”或1996年，MichaelMattson在?篇有關探討?向對象框架的?章中，?先提出了IOC這個概念。對于?向對象設者“控制倒置”。計及編程的基本思想，前?我們已經講了很多了，不再贅述，簡單來說就是把復雜系統(tǒng)分解成相互作?合作的對象，這些對象類通過封裝以后，內部實現對外部是透明的，從?降低了解決問題的復雜度，?且可以靈活地被重?和擴展.IOC理論提出的觀點?體是這樣的：借助于“第三?”實現具有依賴關系的對象之間的，如下圖：?家看到了吧，由于引進了中間位置的“第三?”，也就是IOC容器，使得A，B，C，d這4個對象沒有了耦合關系，齒輪之間的傳動全部依靠“第三?”了，全部對象的控制權全部上繳給“第三?”IOC容器，所以，IOC容器成了整個系統(tǒng)的關鍵核?，它起到了?種類似“粘合劑”的作?，把系統(tǒng)中的所有對象粘合在?起發(fā)揮作?，如果沒有這個“粘合劑”，對象與對象之間會彼此失去聯系，這就是有?把IOC容器?喻成“粘合劑”的由來。我們再來做個試驗：把上圖中間的IOC容器拿掉，然后再來看看這套系統(tǒng)：我們現在看到的畫?，就是我們要實現整個系統(tǒng)所需要完成的全部內容。這時候，A，B，C，d這4個對象之間已經沒有了耦合關系，彼此毫?聯系，這樣的話，當你在實現阿的時候，根本?須再去考慮B，C和d了，對象之間的依賴關系已經降低到了最低程度。所以，如果真能實現IOC容器，對于系統(tǒng)開發(fā)??，這將是?件多么美好的事情，參與開發(fā)的每?成員只要實現??的類就可以了，跟別?沒有任何關系！我們再來看看，控制反轉（IOC）到底為什么要起這么個名字我們來對??下？軟件系統(tǒng)在沒有引?IOC容器之前，如圖1所?，對象甲依賴于對象B，那么對象阿在初始化或者運?到某?點的時候，??必須主動去創(chuàng)建對象?或者使?已經創(chuàng)建的對象B.?論是創(chuàng)建還是使?對象B，控制權都在???上。軟件系統(tǒng)在引?IOC容器之后，這種情形就完全改變了，如圖3所?，由于IOC容器的加?，對象甲與對象?之間失去了直接聯系，所以，當對象甲運?到需要對象?的時候，IOC容器會主動創(chuàng)建?個對象?注?到對象甲需要的地?。通過前后的對?，我們不難看出來：對象甲獲得依賴對象?的過程，由主動?為變?yōu)榱吮粍?為，控制權顛倒過來了，這就是“控制反轉”這個名稱的由來。3.IOC的別名：依賴注?（DI）2004年，MartinFowler探討了同?個問題，既然IOC是控制反轉，那么到底是“哪些??的控制被反轉了呢？”，經過詳細地分析和論證后，他得出了答案：“獲得依賴對象的過程被反轉了”控制被反轉之后，獲得依賴對象的過程由??管理IOC容器主動注?于是，他給“控制反轉“取了?個更合適的名字叫做”依賴注?（DependencyInjection）“。他的這個答案，實際上給出了實現IOC的?法：注?。所謂依賴注?，就是由IOC容器在運?期間，動態(tài)地將某種依賴關系注?到對象之中。所以，依賴注?（DI）和控制反轉（IOC）是從不同的?度的描述的同?件事情，指就是通過引?IOC容器，利?依賴關系注?的?式，實現對象之間的解耦。我們舉?個?活中的例?，來幫助理解依賴注?的過程。?家對USB接?和USB設備應該都很熟悉吧，USB為我們使?電腦提供了很?的?便，現在有很多的外部設備都?持USB接??，F在，我們利?電腦主機和USB接?來實現?個任務：從外部USB設備讀取?個?件。電腦主機讀取?件的時候，它?點也不會關?USB接?上連接的是什么外部設備，?且它確實也?須知道。它的任務就是讀取USB接?，掛接的外部設備只要符合USB接?標準即可。所以，如果我給電腦主機連接上?個U盤，那么主機就從U盤上讀取?件；如果我給電腦主機連接上?個外置硬盤，那么電腦主機就從外置硬盤上讀取?件。掛接外部設備的權?由我作主，即控制權歸我，?于USB接?掛接的是什么設備，電腦主機是決定不了，它只能被動的接受。電腦主機需要外部設備的時候，根本不?它告訴我，我就會主動幫它掛上它想要的外部設備，你看我的服務是多么的到位。這就是我們?活中常見的?個依賴注?的例?。在這個過程中，我就起到了IOC容器的作?。通過這個例?,依賴注?的思路已經?常清楚：當電腦主機讀取?件的時候，我就把它所要依賴的外部設備，幫他掛接上。整個外部設備注?的過程和?個被依賴的對象在系統(tǒng)運?時被注?另外?個對象內部的過程完全?樣。我們把依賴注?應?到軟件系統(tǒng)中，再來描述?下這個過程：對象A依賴于對象B,當對象A需要?到對象B的時候，IOC容器就會?即創(chuàng)建?個對象B送給對象A。IOC容器就是?個對象制造??，你需要什么，它會給你送去，你直接使?就?了，?再也不?去關?你所?的東西是如何制成的，也不?關?最后是怎么被銷毀的，這?切全部由IOC容器包辦。在傳統(tǒng)的實現中，由程序內部代碼來控制組件之間的關系。我們經常使?new關鍵字來實現兩個組件之間關系的組合，這種實現?式會造成組件之間耦合。IOC很好地解決了該問題，它將實現組件間關系從程序內部提到外部容器，也就是說由容器在運?期將組件間的某種依賴關系動態(tài)注?組件中。4.IOC為我們帶來了什么好處我們還是從USB的例?說起，使?USB外部設備?使?內置硬盤，到底帶來什么好處？第?、USB設備作為電腦主機的外部設備，在插?主機之前，與電腦主機沒有任何的關系，只有被我們連接在?起之后，兩者才發(fā)?聯系，具有相關性。所以，?論兩者中的任何??出現什么的問題，都不會影響另??的運?。這種特性體現在軟件?程中，就是可維護性?較好，?常便于進?單元測試，便于調試程序和診斷故障。代碼中的每?個Class都可以單獨測試，彼此互不影響，只要保證??的功能?誤即可，這就是組件之間低耦合或者?耦合帶來的好處。第?、USB設備和電腦主機的之間?關性，還帶來了另外?個好處，?產USB設備的?商和?產電腦主機的?商完全可以是互不相?的?，各?各事，他們之間唯?需要遵守的就是USB接?標準。這種特性體現在軟件開發(fā)過程中，好處可是太?了。每個開發(fā)團隊的成員都只需要關?實現??的業(yè)務邏輯，完全不?去關?其它的??作進展，因為你的任務跟別?沒有任何關系，你的任務可以單獨測試，你的任務也不?依賴于別?的組件，再也不?扯不清責任了。所以，在?個?中型項?中，團隊成員分?明確、責任明晰，很容易將?個?的任務劃分為細?的任務，開發(fā)效率和產品質量必將得到?幅度的提?。第三、同?個USB外部設備可以插接到任何?持USB的設備，可以插接到電腦主機，也可以插接到DV機，USB外部設備可以被反復利?。在軟件?程中，這種特性就是可復?性好，我們可以把具有普遍性的常?組件獨?出來，反復利?到項?中的其它部分，或者是其它項?，當然這也是?向對象的基本特征。顯然，IOC不僅更好地貫徹了這個原則，提?了模塊的可復?性。符合接?標準的實現，都可以插接到?持此標準的模塊中。第四、同USB外部設備?樣，模塊具有熱插拔特性。IOC?成對象的?式轉為外置?式，也就是把對象?成放在配置?件?進?定義，這樣，當我們更換?個實現?類將會變得很簡單，只要修改配置?件就可以了，完全具有熱插撥的特性。以上?點好處，難道還不?以打動我們，讓我們在項?開發(fā)過程中使?IOC框架嗎？5.IOC容器的技術剖析IOC中最基本的技術就是“反射(Reflection)”編程，?前.NetC#、Java和PHP5等語?均?持，其中PHP5的技術書籍中，有時候也被翻譯成“映射”。有關反射的概念和?法，?家應該都很清楚，通俗來講就是根據給出的類名（字符串?式）來動態(tài)地?成對象。這種編程?式可以讓對象在?成時才決定到底是哪?種對象。反射的應?是很?泛的，很多的成熟的框架，?如象Java中的Hibernate、框架，.Net中NHibernate、Spring.Net框架都是把“反射”做為最基本的技術?段。反射技術其實很早就出現了，但?直被忽略，沒有被進?步的利?。當時的反射編程?式相對于正常的對象?成?式要慢?少得10倍?，F在的反射技術經過改良優(yōu)化，已經?常成熟，反射?式?成對象和通常對象?成?式，速度已經相差不?了，?約為1-2倍的差距。我們可以把IOC容器的?作模式看做是??模式的升華，可以把IOC容器看作是?個??，這個???要?產的對象都在配置?件中給出定義，然后利?編程語?的的反射編程，根據配置?件中給出的類名?成相應的對象。從實現來看，IOC是把以前在???法?寫死的對象?成代碼，改變?yōu)橛膳渲?件來定義，也就是把??和對象?成這兩者獨?分隔開來，?的就是提?靈活性和可維護性。6.IOC容器的?些產品SunONE技術體系下的IOC容器有：輕量級的有Spring、Guice、PicoContainer、Avalon、HiveMind；重量級的有EJB；不輕不重的有JBoss，Jdon等等。Spring框架作為Java開發(fā)中SSH(Struts、Spring、Hibernate)三劍客之?，?中?項?中都有使?，?常成熟，應??泛，EJB在關鍵性的?業(yè)級項?中也被使?，?如某些電信業(yè)務。.Net技術體系下的IOC容器有：Spring.Net、Castle等等。Spring.Net是從Java的Spring移植過來的IOC容器，Castle的IOC容器就是Windsor部分。它們均是輕量級的框架，?較成熟，其中Spring.Net已經被逐漸應?于各種項?中。7.使?IOC框架應該注意什么

使?IOC框架產品能夠給我們的開發(fā)過程帶來很?的好處，但是也要充分認識引?IOC框架的缺點，做到?中有數，杜絕濫?框架。第?、軟件系統(tǒng)中由于引?了第三?IOC容器，?成對象的步驟變得有些復雜，本來是兩者之間的事情，?憑空多出?道?續(xù)，所以，我們在剛開始使?IOC框架的時候，會感覺系統(tǒng)變得不太直觀。所以，引?了?個全新的框架，就會增加團隊成員學習和認識的培訓成本，并且在以后的運?維護中，還得讓新加?者具備同樣的知識體系。第?、由于IOC容器?成對象是通過反射?式，在運?效率上有?定的損耗。如果你要追求運?效率的話，就必須對此進?權衡。第三、具體到IOC框架產品(?如：Spring)來講，需要進??量的配制?作，?較繁瑣，對于?些?的項???，客觀上也可能加??些?作成本。第四、I