對IOC和DI的理解.doc

對IOC和DI的理解首先說一下什么是IOC和DI，IOC是InversionofControl（控制反轉(zhuǎn)）的簡寫，DI是DependencyInjection（依賴注入）的簡寫，martinfowler對IOC的解釋為：“Inversionofcontrolisacommoncharacteristicofframeworks，sosayingthattheselightweightcontainersarespecialbecausetheyuseinversionofcontrolislikesayingmycarisspecialbecauseithaswheels.” 我想對這一概念進行一個個人的闡述，以方便我的理解。控制反轉(zhuǎn)，從字面意思來看，就是控制權(quán)由被動變主動又變?yōu)楸粍?，或被動變主動又變?yōu)楸粍印倪@個角度來說，IOC就變得非常容易理解了。 舉個例子：你的主管要求你做一件事情，這個時候就存在這么幾個過程， 1、主管命令你做事情（這個時候主動權(quán)在主管，你是被動的） 2、你接到命令做事情（這個時候主題是你，你是主動的，控制權(quán)在你手里） 3、你完成事情（這個時候主題依然是你，控制權(quán)在你手里） 4、報告主管做完事情（主動權(quán)又叫交到主管手里了） 上面的整個過程就完成了一次IOC，從上面可以看出，IOC的基本思想是控制權(quán)的轉(zhuǎn)換過程。 舉個代碼的例子： 假如有ClassA，ClassB，在A內(nèi)部會初始化一個B，調(diào)用B的一個方法DoMethod publicClassB publicvoidDoMethod（） /dosomthing； publicClassA publicvoidExcute（） Bb=newB（）； b.DoMethod（）； 假如在Main函數(shù)中如下執(zhí)行： Aa=newA（）； a.Excute（）； 從這兩行代碼來看，事實上也存在一個IOC的過程，aba，理解的關(guān)鍵點就在A的內(nèi)部調(diào)用Excute的時候，方法b.DoMethod的執(zhí)行。 理解了IOC，我們再看一下DI，從上面A調(diào)用B我們可以看出，在初始化一個A的實例時，也必須實例化一個B，也就是說如果沒有B或者B出了問題，A就無法實例化，這就產(chǎn)生了一種依賴，就是A依賴B，這種依賴從設(shè)計的角度來說就是耦合，顯然它是無法滿足高內(nèi)聚低耦合的要求的。這個時候就需要解耦，當然解耦有很多種方法，而DI就是其中一種。不管任何一種解耦方法，都不是說使A和B完全沒有關(guān)系，而是把這種關(guān)系的實現(xiàn)變得隱晦，不那么直接，但是又很容易實現(xiàn)，而且易于擴展，不像上面的代碼那樣，直接new一個B出來。那就是為什么我們總是把IOC和DI聯(lián)系到一起，是因為DI的基本思想就是IOC，而體現(xiàn)IOC思想的方法還有另外一個，那就是ServiceLocator，這個方法好像涉及到的很少。 DI，依賴注入，從字面意思就可以看出，依賴是通過外接注入的方式來實現(xiàn)的。這就實現(xiàn)了解耦，而DI的方式通常有三種： 構(gòu)造器注入 屬性設(shè)置器注入 接口注入（我感覺接口注入是同時存在于上兩種注入方式的，而不應(yīng)該獨立出來） 以上的闡述只是為了先讓我們能對IOC和DI有一個感性的理解，那么IOC它真正解決的問題是什么呢？我們講了那么多主動、被動的問題，那我們是從什么視角來看待這個問題的呢？為什么你是主動，而我不是主動呢？這就需要一個參照物，這個參照物是什么呢？就是容器，在容器中來體現(xiàn)主動和被動?！坝猛ㄋ自捴v，就是由容器控制程序之間的關(guān)系，而非傳統(tǒng)實現(xiàn)中，由程序代碼直接操控。這也就是所謂”控制反轉(zhuǎn)“的概念所在：控制權(quán)由應(yīng)用代碼中轉(zhuǎn)到了外部容器，控制權(quán)的轉(zhuǎn)移，是所謂反轉(zhuǎn)，這是通常對IOC的一個解釋。從容器的角度來看主動和被動，和由容器來控制程序之間的關(guān)系，應(yīng)該是相通的，是一個意思。到這里我們就應(yīng)該基本明白了，IOC要解決的就是程序之間調(diào)用的一個問題，它應(yīng)該是一個邏輯層面的東西，是一個指揮中心，就像一支樂隊的指揮，而程序就是樂器，通過指揮來協(xié)調(diào)各種樂器，來演奏出美好的音樂來Resource的概念Resource在Sping框架中起著不可或缺的作用，Sping框架使用Resource裝載各種資源，這些資源包括配置文件資源、國際化屬性文件資源等。下面我們來了解一下Resource的具體實現(xiàn)類。 ByteArrayResource：二進制數(shù)組表示的資源，二進制數(shù)組源可以在內(nèi)存中通過程序構(gòu)造。 ClassPathResource：類路徑下的資源，資源以相對于類路徑的方式表示，如：new ClassPathResource(com/baobaotao/beanfactory/bean.xml)。 FileSystemResource：文件系統(tǒng)資源，資源以文件系統(tǒng)路徑的方式表示，如：new FileSystemResource(c:beans.xml)。 InputSteamResource：以輸入流返回表示的資源。 ServletContextResource：為訪問Web容器上下文中的資源而設(shè)計的類，負責(zé)從Web應(yīng)用根目錄中加載資源，它支持以流和Url的方式訪問，在WAR解包的情況下，也可以通過File的方式訪問，該類還可以直接從JAR包中訪問資源。 UrlResource：Url封裝了.URL，它使用戶能夠訪問任何可以通過URL表示的資源，如文件系統(tǒng)的資源、HTTP資源、FTP資源等。 有了這個抽象的資源類后，我們就可以將Spring的配置信息放置在任何地方（如數(shù)據(jù)庫、LDAP中），只要最終可以通過Resource接口返回配置信息就可以了。Java標準的 .URL接口和多種URL前綴處理類并不能很好地滿足所有底層資源訪問的需要。比如，還沒有能從類路徑或者ServletContext 的相對路徑獲得資源的標準URL實現(xiàn)。雖然能為特定的URL前綴注冊新的處理類(類似已有前綴 http: 的處理類)，但是這樣做通常比較復(fù)雜，而且URL接口還缺少一些有用的功能，比如檢查指向的資源是否存在的方法。4.2. Resource 接口Spring的 Resource 接口是為了提供更強的訪問底層資源能力的抽象。 public interface Resource extends InputStreamSource boolean exists(); boolean isOpen(); URL getURL() throws IOException; File getFile() throws IOException; Resource createRelative(String relativePath) throws IOException; String getFilename(); String getDescription();public interface InputStreamSource InputStream getInputStream() throws IOException;Resource 接口一些比較重要的方法如下： getInputStream(): 定位并打開資源，返回讀取此資源的一個 InputStream。每次調(diào)用預(yù)期會返回一個新的 InputStream，由調(diào)用者負責(zé)關(guān)閉這個流。exists(): 返回標識這個資源在物理上是否的確存在的 boolean 值。isOpen(): 返回標識這個資源是否有已打開流的處理類的 boolean 值。如果為 true，則此InputStream 就不能被多次讀取，而且只能被讀取一次然后關(guān)閉以避免資源泄漏。除了 InputStreamResource，常見的resource實現(xiàn)都會返回 false。 getDescription(): 返回資源的描述，一般在與此資源相關(guān)的錯誤輸出時使用。此描述通常是完整的文件名或?qū)嶋H的URL地址。 其它方法讓你獲得表示該資源的實際的 URL 或 File 對象(如果隱含的實現(xiàn)支持該方法并保持一致的話)。 Spring自身處理資源請求的多種方法聲明中將Resource 抽象作為參數(shù)而廣泛地使用。 Spring APIs中的一些其它方法(比如許多ApplicationContext的實現(xiàn)構(gòu)造函數(shù))，使用普通格式的 String 來創(chuàng)建與context相符的Resource，也可以使用特殊的路徑String前綴來讓調(diào)用者指定創(chuàng)建和使用特定的 Resource 實現(xiàn)。 Resource不僅被Spring自身大量地使用，它也非常適合在你自己的代碼中獨立作為輔助類使用。用戶代碼甚至可以在不用關(guān)心Spring其它部分的情況下訪問資源。這樣的確會造成代碼與Spring之間的耦合，但也僅僅是與很少量的輔助類耦合。這些類可以作為比 URL 更有效的替代，而且與為這個目的而使用其它類庫基本相似。 需要注意的是 Resource 抽象并沒有改變功能：它盡量使用封裝。 比如 UrlResource 封裝了URL，然后使用被封裝的 URL 來工作。 4.3. 內(nèi)置 Resource 實現(xiàn)Spring提供了很多 Resource 的實現(xiàn)： 4.3.1. UrlResource UrlResource 封裝了.URL，它能夠被用來訪問任何通過URL可以獲得的對象，例如：文件、HTTP對象、FTP對象等。所有的URL都有個標準的 String表示，這些標準前綴可以標識不同的URL類型，包括file:訪問文件系統(tǒng)路徑，http: 通過HTTP協(xié)議訪問的資源，ftp: 通過FTP訪問的資源等等。 UrlResource 對象可以在Java代碼中顯式地使用 UrlResource 構(gòu)造函數(shù)來創(chuàng)建。但更多的是通過調(diào)用帶表示路徑的 String 參數(shù)的API函數(shù)隱式地創(chuàng)建。在后一種情況下，JavaBeans的 PropertyEditor 會最終決定哪種類型的 Resource 被創(chuàng)建。如果這個字符串包含一些眾所周知的前綴，比如 classpath:，它就會創(chuàng)建一個對應(yīng)的已串行化的 Resource。 然而，如果不能分辨出這個前綴，就會假定它是個標準的URL字符串，然后創(chuàng)建UrlResource。 4.3.2. ClassPathResource 這個類標識從classpath獲得的資源。它會使用線程context的類加載器(class loader)、給定的類加載器或者用來載入資源的給定類。如果類路徑上的資源存在于文件系統(tǒng)里，這個 Resource 的實現(xiàn)會提供類似于java.io.File的功能。而如果資源是存在于還未解開(被servlet引擎或其它的環(huán)境解開)的jar包中，這些 Resource 實現(xiàn)會提供類似于.URL 的功能。 ClassPathResource對象可以在Java代碼中顯式地使用ClassPathResource 構(gòu)造函數(shù)來創(chuàng)建。但更多的是通過調(diào)用帶表示路徑的String參數(shù)的API函數(shù)隱式地創(chuàng)建。在后一種情況下，JavaBeans的 PropertyEditor 會分辨字符串中 classpath: 前綴，然后相應(yīng)創(chuàng)建 ClassPathResource。 4.3.3. FileSystemResource 這是為處理 java.io.File 而準備的Resource實現(xiàn)。它既可以作為File提供，也可以作為URL。 4.3.4. ServletContextResource 這是為 ServletContext 資源提供的 Resource 實現(xiàn)，它負責(zé)解析相關(guān)web應(yīng)用根目錄中的相對路徑。 它始終支持以流和URL的方式訪問。 但是只有當web應(yīng)用包被解開并且資源在文件系統(tǒng)的物理路徑上時，才允許以 java.io.File 方式訪問。是否解開并且在文件系統(tǒng)中訪問，還是直接從JAR包訪問或以其它方式訪問如DB(這是可以想象的)，僅取決于Servlet容器。 4.3.5. InputStreamResource 這是為給定的 InputStream 而準備的 Resource 實現(xiàn)。它只有在沒有其它合適的 Resource 實現(xiàn)時才使用。而且，只要有可能就盡量使用 ByteArrayResource 或者其它基于文件的Resource 實現(xiàn)。 與其它 Resource 實現(xiàn)不同的是，這是個 已經(jīng) 打開資源的描述符-因此 isOpen() 函數(shù)返回 true。 如果你需要在其它位置保持這個資源的描述符或者多次讀取一個流，請不要使用它。 4.3.6. ByteArrayResource 這是為給定的byte數(shù)組準備的 Resource 實現(xiàn)。 它會為給定的byte數(shù)組構(gòu)造一個 ByteArrayInputStream。 它在從任何給定的byte數(shù)組讀取內(nèi)容時很有用，因為不用轉(zhuǎn)換成單一作用的 InputStreamResource。 4.4. ResourceLoader ResourceLoader 接口由能返回(或者載入)Resource 實例的對象來實現(xiàn)。 public interface ResourceLoader Resource getResource(String location);所有的application context都實現(xiàn)了 ResourceLoader 接口， 因此它們可以用來獲取Resource 實例。 當你調(diào)用特定application context的 getResource() 方法， 而且資源路徑并沒有特定的前綴時，你將獲得與該application context相應(yīng)的 Resource 類型。例如：假定下面的代碼片斷是基于ClassPathXmlApplicationContext 實例上執(zhí)行的： Resource template = ctx.getResource(some/resource/path/myTemplate.txt);這將返回ClassPathResource；如果是基于FileSystemXmlApplicationContext 實例上執(zhí)行的，那你將獲得FileSystemResource。而對于 WebApplicationContext 你將獲得ServletContextResource，依此類推。 這樣你可以在特定的application context中用流行的方法載入資源。 另一方面，無論什么類型的application context， 你可以通過使用特定的前綴 classpath: 強制使用ClassPathResource。 Resource template = ctx.getResource(classpath:some/resource/path/myTemplate.txt);同樣的，你可以用任何標準的 .URL 前綴，強制使用 UrlResource ： Resource template = ctx.getResource(file:/some/resource/path/myTemplate.txt);Resource template = ctx.getResource(/resource/path/myTemplate.txt);下面的表格概述了 String 到 Resource 的轉(zhuǎn)換規(guī)則： Table 4.1. Resource strings前綴 例子 說明 classpath: classpath:com/myapp/config.xml 從classpath中加載。 file: file:/data/config.xml 作為 URL 從文件系統(tǒng)中加載。 http: http:/myserver/logo.png 作為 URL 加載。 (none) /data/config.xml 根據(jù) ApplicationContext 進行判斷。 a 參考標題為 Section 4.7.3, “ FileSystemResource 提示” 的章節(jié)。 4.5. ResourceLoaderAware 接口ResourceLoaderAware是特殊的標記接口，它希望擁有一個ResourceLoader 引用的對象。 public interface ResourceLoaderAware void setResourceLoader(ResourceLoader resourceLoader);當實現(xiàn)了 ResourceLoaderAware接口的類部署到application context(比如受Spring管理的bean)中時，它會被application context識別為 ResourceLoaderAware。接著application context會調(diào)用setResourceLoader(ResourceLoader)方法，并把自身作為參數(shù)傳入該方法(記住，所有Spring里的application context都實現(xiàn)了ResourceLoader接口)。 既然 ApplicationContext 就是ResourceLoader，那么該bean就可以實現(xiàn) ApplicationContextAware接口并直接使用所提供的applicatio