Spring中BeanFactory與FactoryBean的作用與區別

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的動機在的第四章中有描述，在TheServerSide網站上的有免費的PDF(). 通過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 屬性。