Spring簡介 
關于Spring Framework，今年夏天你可能已經聽見很多的議論。在本文中,我將試圖解釋Spring能完成什么，和我怎么會認為它能幫助你開發J2EE應用程序。 

另一framework？ 
你可能正在想“不過是另外一個的framework”。當已經有許多開放源代碼(和專有) J2EE framework時，為什么你應該費心讀這篇文章,或下載Spring Framework？ 

我相信Spring是獨特的,因為若干個原因: 
. 它定位的領域是許多其他流行的framework沒有的。Spring關注提供一種方法管理你的業務對象。 
. Spring是全面的和模塊化的。Spring有分層的體系結構,這意味著你能選擇使用它孤立的任何部分,它的架構仍然是內在穩定的。因此從你的學習中，你可得到最大的價值。例如,你可能選擇僅僅使用Spring來簡單化JDBC的使用,或用來管理所有的業務對象。 
. 它的設計從底部幫助你編寫易于測試的代碼。Spring是用于測試驅動工程的理想的framework。 

Spring對你的工程來說，它不需要一個以上的framework。Spring是潛在地一站式解決方案,定位于與典型應用相關的大部分基礎結構。它也涉及到其他framework沒有考慮到的內容。 

盡管它僅僅是一個從2003年2月才開始的開源工程，但Spring有較長的歷史根基。這個開源工程是起源自我在2002年后期出版的《Expert One-on-One J2EE設計與開發》書中的基礎代碼。這本書展示了Spring背后的基礎架構。然而,這個基礎架構的概念要追溯到2000年的早些時候,并且反映了我為一系列成功的商業工程開發基礎結構的經驗。 

從2003年1月，Spring已經落戶于SourceForge上。現在有10個開發人員,其中6是高度投入的積極分子。 

Spring的架構性的好處 

在我們進入細節以前，讓我們看一下Spring可以給一個工程帶來的一些好處: 

. Spring能有效地組織你的中間層對象,無論你是否選擇使用了EJB。如果你僅僅使用了Struts或其他的包含了J2EE特有APIs的framework，你會發現Spring關注了遺留下的問題，。 

. Spring能消除在許多工程上對Singleton的過多使用。根據我的經驗，這是一個主要的問題，它減少了系統的可測試性和面向對象特性。 

. Spring能消除使用各種各樣格式的屬性定制文件的需要,在整個應用和工程中，可通過一種一致的方法來進行配置。曾經感到迷惑，一個特定類要查找迷幻般的屬性關鍵字或系統屬性,為此不得不讀Javadoc乃至源編碼嗎？有了Spring，你可很簡單地看到類的JavaBean屬性。倒置控制的使用(在下面討論)幫助完成這種簡化。 

. Spring能通過接口而不是類促進好的編程習慣，減少編程代價到幾乎為零。 
. Spring被設計為讓使用它創建的應用盡可能少的依賴于他的APIs。在Spring應用中的大多數業務對象沒有依賴于Spring。 
. 使用Spring構建的應用程序易于單元測試。 
. Spring能使EJB的使用成為一個實現選擇,而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務接口，卻不會影響調用代碼。 
. Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適于許多web應用。例如,Spring能使用AOP提供聲明性事務而不通過使用EJB容器，如果你僅僅需要與單個的數據庫打交道，甚至不需要JTA實現。 
. Spring為數據存取提供了一致的框架,不論是使用JDBC或O/R mapping產品（如Hibernate）。 
Spring確實使你能通過最簡單可行的解決辦法解決你的問題。這些特性是有很大價值的。 

Spring能做什么？ 

Spring提供許多功能,在此我將快速地依次展示其各個主要方面。 

任務描述： 
首先,讓我們明確Spring范圍。盡管Spring覆蓋了許多方面，但我們已經有清楚的概念，它什么應該涉及和什么不應該涉及。 

Spring的主要目的是使J2EE易用和促進好編程習慣。 
Spring不重新開發已有的東西。因此，在Spring中你將發現沒有日志記錄的包,沒有連接池,沒有分布事務調度。這些均有開源項目提供(例如Commons Logging 用來做所有的日志輸出，或Commons DBCP用來作數據連接池),或由你的應用程序服務器提供。因為同樣的的原因，我們沒有提供O/R mapping層，對此，已有有好的解決辦法如Hibernate和JDO。 

Spring的目標是使已存在的技術更加易用。例如,盡管我們沒有底層事務協調處理，但我們提供了一個抽象層覆蓋了JTA或任何其他的事務策略。 

Spring沒有直接和其他的開源項目競爭，除非我們感到我們能提供新的一些東西。例如，象許多開發人員，我們從來沒有為Struts高興過，并且感到在MVC web framework中還有改進的余地。在某些領域，例如輕量級的IoC容器和AOP框架，Spring有直接的競爭，但是在這些領域還沒有已經較為流行的解決方案。(Spring在這些區域是開路先鋒。) 

Spring也得益于內在的一致性。 
所有的開發者都在唱同樣的的贊歌,基礎想法依然是Expert One-on-One J2EE設計與開發的那些。 
并且我們已經能夠使用一些主要的概念,例如倒置控制，來處理多個領域。 

Spring在應用服務器之間是可移植的。 
當然保證可移植性總是一次挑戰，但是我們避免任何特定平臺或非標準化,并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的應用服務器上的用戶。 

倒置控制容器 
Spring的設計核心是 org.springframework.beans 包, 為與JavaBeans一起工作而設計。 這個包一般不直接被用戶使用, 但作為基礎為更多的其他功能服務. 下一個較高層面的抽象是"Bean Factory"。 Spring bean factory 是一個普通的Factory，它使對象能夠按名稱獲取，并且能管理對象之間的關系。 

Bean factories 支持兩種對象模式: 
. Singleton：在此模式中，有一個具有特定名稱的共享對象實例，它在查找時被獲取。這是默認的，而且是最為經常使用的。它對于無狀態對象是一種理想的模式。 
.Prototype：在此模式中，每次獲取將創建一個獨立的對象。例如，這可以被用于允許用戶擁有他們自己的對象。 

由于 org.springframwork.beans.factory.BeanFactory是一個簡單的接口，它能被為了底層存儲方法而實現。你能夠方便地實現你自己的BeanFactory，盡管很少用戶需要。最為常用的定義是： 
.XmlBeanFactory： 可解析簡單直觀的定義類和命名對象屬性的XML結構。 我們提供了一個DTD來使編寫更容易。 
.ListableBeanFactoryImpl：可提供解析存放在屬性文件中的bean定義，和可通過編程創建BeanFactories。 

每個bean定義可能是一個POJO(通過類名和JavaBean初始屬性定義)，或是一個FactoryBean。FactoryBean接口添加了一個間接層。通常，這用于使用AOP或其他方法來創建代理對象：例如，添加了聲明性事務管理的代理。(這在概念上和EJB偵聽相似，但在實踐中實現更簡單。) 

BeanFactories能在一個層次結構中可選擇性的參與，根據來自祖先的繼承定義。這使在整個應用中公共配置的共享成為可能，雖然個別資源，如controller servlets，也擁有他們自己的獨立的對象集合。 

這種使用JavaBeans的動機在<Expert One-on-One J2EE Design and Development>的第四章中有描述，在TheServerSide網站上的有免費的PDF(http://www.theserverside.com/resources/article.jsp?l=RodJohnsonInterview).  

通過BeanFactory概念，Spring成為一個倒置控制的容器。(我非常不喜歡container這個術語，因為它使人聯想到重量級容器，如EJB容器。Spring的BeanFactory是一個可通過一行代碼創建的容器，并且不需要特殊的部署步驟。) 

位于倒置控制背后的概念是在Hollywood原則中經常表述："Don’t call me, I’ll call you." IoC將控制職責搬進了框架中，并脫離應用代碼。涉及到配置的地方，意思是說在傳統的容器體系結構中，如EJB，一個組件可以調用容器并問“我需要它給我做工作的對象X在哪里?”；使用IoC容器則只需指出組件需要X對象，在運行時容器會提供給它。容器基于方法名作出這種說明，或可能根據配置數據如XML。 

倒置控制的幾個重要好處。如： 
. 因為組件不需要在運行時間尋找合作者，所以他們可以更簡單的編寫和維護。在Spring的IoC版本里，組件通過暴露JavaBean的setter方法表達他們依賴的其他組件。這相當于EJB通過JNDI來查找，EJB查找需要開發人員編寫代碼。 
. 同樣原因，應用代碼更容易測試。JavaBean屬性是簡單的，Java核心的，并且容易測試：僅編寫一個包含自身的Junit測試方法用來創建對象和設置相關屬性即可。 
. 一個好的IoC實現隱藏了強類型。如果你使用一個普通的factory來尋找合作者，你必須通過類型轉換將返回結果轉變為想要的類型。這不是一個主要問題，但是不雅觀。使用IoC，你在你的代碼中表達強類型依賴，框架將負責類型轉換。這意味著在框架配置應用時，類型不匹配將導致錯誤；在你的代碼中，你無需擔心類型轉換異常。 
. 大部分業務對象不依賴于IoC容器的APIs。這使得很容易使用遺留下來的代碼，且很容易的使用對象無論在容器內或不在容器內。例如，Spring用戶經常配置Jakarta Commons DBCP數據源為一個Spring bean：不需要些任何定制代碼去做這件事。我們說一個IoC容器不是侵入性的：使用它并不會使你的代碼依賴于它的APIs。任何JavaBena在Spring bean factory中都能成為一個組件。 

最后應該強調的是，IoC 不同于傳統的容器的體系結構( 如EJB), 應用代碼最小程度的依靠于容器。這意味著你的業務對象可以潛在的被運行在不同的IoC 框架上-或者在任何框架之外-不需要任何代碼改。 

以我的經驗和作為Spring用戶，過分強調IoC給應用代碼帶來的好處是不容易的。 

IoC不是一個新概念，但是它在J2EE團體里面剛剛到達黃金時間。 有一些可供選擇的IoC 容器: notably, Apache Avalon, PicoContainer 和 HiveMind. Avalon 不會成為特別流行的，盡管它很強大而且有很長的歷史。Avalon是相當的重量級和復雜的，并且看起來比新的IoC解決方案更具侵入性。 PicoContainer是一個輕量級而且更強調通過構造器表達依賴性而不是JavaBean 屬性。 與Spring不同，它的設計允許每個類型一個對象的定義(可能局限性結果來自它對Java代碼外的元數據的拒絕)。作為和Spring and PicoContainer and other IoC frameworks的比較，可參看文章http://www.springframework.org/docs/lightweight_container.html.  這個業面包含了PicoContainer站點鏈接 。 

Spring BeanFactories 是非常輕量級的。用戶已經成功地將他們應用在applets中和單獨的Swing應用中。(它們也很好地工作在EJB容器中。) 沒有特殊的部署步驟和可察覺的啟動時間。這個能力表明一個容器在應用的任何層面差不多立即可以發揮非常大的價值。 

Spring BeanFactory 概念應用貫穿于Spring整體， 而且是Spring如此內在一致的關鍵原因。在IoC容器中，Spring也是唯一的，它使用IoC作為基礎概念貫穿于整個框架。 

對應用開發人員，最重要的是，一個或多個BeanFactory提供一個定義明確的業務對象層。這是類似的，但比local session bean層更簡單。與EJBs不同，在這個層中的對象可能是相關的，并且他們的關系被自己的factory管理。有一個定義明確的業務對象層對于一個成功的體系結構是非常重要的。 

Spring ApplicationContext 是BeanFactory的子接口,為下列提供支持: 
.消息尋找，國際化支持 
.事件機制，允許應用對象發布和隨意地注冊為事件監聽 
.便攜文件和資源訪問 

XmlBeanFactory示例 
Spring用戶通常在XML“bean定義”文件中配置他們的應用。Spring的XML bean定義文檔的根是一個<beans> 元素。該元素包含一個或多個 <bean>定義。我們一般指定一個bean定義的類和屬性。我們也必須指定ID作為標識，我們將在代碼中使用該標志。 
讓我們來看一個簡單的例子，在J2EE應用中常看到用來配置三個應用對象： 
. J2EE DataSource 
. 使用DataSource的DAO 
. 在處理過程中使用DAO的業務對象 

在下面的例子中，我們使用一個來自Jakarta Commons DBCP項目的BasicDataSource。這個class(和其他存在的class一樣)可以簡單地被應用在Spring bean factory中，因為它提供了JavaBean格式的配置。需要在shutdown時被調用的Close方法可通過Spring的"destroy-method"屬性被注冊，來避免BasicDataSource需要實現任何Spring 接口。 

代碼: <textarea>
<beans> 
    <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
        <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property> 
        <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property> 
        <property name="username"><value>root</value></property> 
    </bean> </textarea>


我們感興趣的BasicDataSource的所有屬性都是String型的，因此，我們用<value>元素來指定他們的值。如果必要的話，Spring使用標準的 JavaBean屬性編輯器機制來轉換String以表示其他的類型。 

現在，我們定義了DAO，它有一個對DataSource的bean引用。Bean間關系通過<ref>元素來指定: 
代碼: <textarea>
<bean id="exampleDataAccessObject" class="example.ExampleDataAccessObject"> 
        <property name="dataSource"> 
            <ref bean="myDataSource"/> 
        </property> 
    </bean> </textarea>

業務對象有一個DAO的引用和一個int型屬性(exampleParam): 
代碼: 
<textarea><bean id="exampleBusinessObject" class="example.ExampleBusinessObject"> 
        <property name="dataAccessObject"><ref bean="exampleDataAccessObject"/></property> 
        <property name="exampleParam"><value>10</value></property> 
    </bean></beans> </textarea> 


對象間的關系一般在配置中明確地設置，象此例子一樣。我們認為這樣做是件好事情。無論如何，Spring也提供了我們叫做"autowire"的支持， 一個la PicoContainer，在那里，它可以指出bean間的依賴關系。這樣做的局限性－如使用PicoContainer－是如果有一個特殊類型的多個Bean，要作出一個類型應該與哪個實例相關的判斷將是不可能的。好的方面，在factory初始化后，不理想的依賴可能會被捕獲到。(Spring 也為清楚的配置提供一種可選的依賴檢查，它可以完成這個目的) 

如果我們不想明確的編寫他們的關系，在上面的例子中，我們可如下使用autowire特性： 
<textarea> 
<bean id="exampleBusinessObject" class="example.ExampleBusinessObject" autowire="byType"> 
<property name="exampleParam"><value>10</value></property> 
</bean> </textarea> 

使用這用用法，Spring將找出exampleBusinessObject的dataSource屬性應該被設置為在當前BeanFactory中找到的DataSource實現。在當前的BeanFactory中，如果所需要類型的bean不存在或多于一個，將產生一個錯誤。我們依然要設置exampleParam屬性，因為它不是一個引用。 

Autowire支持和依賴檢查剛剛加入CVS并將在Spring 1.0 M2(到10/20,2003)中提供。本文中所討論的所有其他特性都包含在當前1.0 M1版本中。 

來自Java代碼的外在關系比硬編碼有極大的好處，因為改變XML文件而無需改變一行Java代碼是可能的。例如，我們可以簡單地改變myDataSource的bean定義來提供不同的bean class以使用一個可供選擇的連接池，或者一個測試數據源。 在一個單獨可選的XML片斷中，我們可以用Spring的JNDI 定位FactoryBean來從application server獲取一個數據源。 

現在讓我們來看例子中業務對象的java 代碼。注意下面列出的代碼中沒有對Spring的依賴。不像EJB容器，Spring BeanFactory不是侵入性的：在應用對象里面你通常不需要對他們編碼。 
代碼: 
public class ExampleBusinessObject implements MyBusinessObject { 

   private ExampleDataAccessObject dao; 
   private int exampleParam; 

   public void setDataAccessObject(ExampleDataAccessObject dao) { 
      this.dao = dao; 
   } 

   public void setExampleParam(int exampleParam) { 
      this.exampleParam = exampleParam; 
   } 

   public void myBusinessMethod() { 
      // do stuff using dao 
   } 
} 


注意屬性設置器，在bean定義文檔中，它對應與XML引用。這些將在對象使用之前被Spring調用. 

這些應用bean不需要依賴于Spring。他們不需要實現任何Spring接口或者繼承Spring的類：他們只需要遵守JavaBeans命名習慣。在Spring 應用環境之外重用它們是非常簡單的，例如，一個測試環境。只是例示它有默認的構造器，并且通過setDataSource()和setExampleParam()的調用來手工設置它的屬性。只要你有一個沒有參數的構造器，如果你想在單行代碼支持程序化的創建，你可以自由定義其他的帶有多個屬性構建的器。 

注意，在業務接口中沒有聲明的JavaBean屬性將會一起工作。 他們是一個實現細節。我們可以插入帶有不同bean屬性的不同的實現類而不影響連接對象或者調用代碼。 

當然，Spring XML bean factories 有更多的功能沒有在這里描述，但是，這將給你一種基本使用的感覺。同時，簡單的屬性和有JavaBean屬性編輯器的屬性，Spring可以自動處理lists,maps和java.util.Properties.