POJO應用框架：Spring Vs. EJB 3.0

2019-11-18 13:00:06

字體：大中小

來源：轉載

供稿：網友

　　愛因斯坦曾經說：“任何事情都應該越簡單越好，而不是比較簡單。”實際上，科學真理的目的就是在假設的前提下去簡化一個理論，這樣，人們可以去關注真正重要的問題。在企業軟件開發中，道理是一樣的。
　　
　　簡化企業軟件開發的一個要害是，提供一個這樣的應用框架：它可以使開發人員不用關注于很多復雜的問題，比如事務處理、安全和持久化等。一個設計良好的框架將提升代碼的可復用性，提高開發者的效率，并得到更高質量的軟件。然而，目前J2EE 1.4下的EJB 2.1 框架被廣泛認為是設計較差而且過度復雜的。不滿足于EJB2.1框架，java開發者使用了很多其他的中間件服務產品。最值得關注的是，以下兩個框架吸引了大量開發者的愛好和積極反饋。這兩個框架很可能成為未來企業JAVA應用開發框架的選擇。
　　
　　SPRing框架是一個廣受歡迎的但是非標準的開源框架。它主要由Interface21公司開發和控制。Spring框架的體系結構是基于注射依靠（DI）模式。Spring框架使用了大量的xml配置文件，它可以獨立應用，或者在現有的應用服務器上工作。
　　
　　EJB 3.0框架是JCP定義的并且被所有主流J2EE提供商支持的標準框架。EJB 3.0規范的預發布版本目前已經有開源的和商業的實現，如JBOSS和Oracle。EJB 3.0大量使用了JAVA注解（Java annotations，是JDK1.5提供的新功能。譯者注）
　　
　　這兩個框架有著一個共同的核心設計理念：它們的目標是為松耦合的POJO類提供中間件服務。框架通過在運行時截取執行環境，或將服務對象注射給POJO類的方式，將應用服務和POJO類“連接”起來。POJO類本身并不關注如何“連接”，而且也很少依靠于框架。這樣，開發者可以將注重力集中在業務邏輯上，可以對他們的POJO類進行與框架無關的單元測試。并且，由于POJO類不需要繼續框架的類或實現框架提供的接口，開發者可以在更加靈活性的基礎上構建繼續體系，和搭建應用。
　　
　　盡管有著共同的理念，但這兩個框架采取了不同的方式來提供POJO服務。由于已經出版了大量的比較Spring與EJB2.1或者EJB3.0與EJB2.1的書籍和文章，而沒有關于比較Spring和EJB3.0的認真研究，因此，本文將考察它們之間幾個要害的不同，討論他們優缺點。本文談到的主題同樣適用于其他不太有名的但同樣提供“松耦合POJO” 設計的企業中間件框架。我希望，這篇文章可以幫助你選者最合適的你需求的框架。
　　
　　提供商無關性
　　
　　開發者選擇JAVA平臺的一個最重要的原因就是它的提供廠商無關性。EJB 3.0是一個被設計為對提供商沒有依靠性的開放的標準。EJB 3.0規范由企業JAVA社區的主流開源組織和廠商共同編寫和支持的。EJB 3.0框架使開發者的應用程序實現可以獨立于應用服務器。比如，JBoss的EJB 3.0的實現是基于Hibernate的，Oracle的EJB 3.0實現是基于TopLink的，但是，在JBoss或者Oracle上跑應用程序，開發者既不需要去學習Hibernate，也不需要學習TopLink提供的獨特API。廠商無關性使EJB 3.0框架區別于當前其他任何的POJO中間件框架。
　　
　　然而，就象很多EJB 3.0的批評者很快指出的一樣，目前EJB 3.0規范正在編寫還未完全完成最終發布版。很有可能，還需要1至2年，EJB 3.0才會被主流J2EE廠商完全接受。但是，就算你的應用服務器本身不支持EJB 3.0，你也可以通過下載和安裝一個“可嵌入的” EJB 3.0產品，來使你的應用服務器支持EJB 3.0應用。比如，JBoss“可嵌入的” EJB 3.0產品是開源的，它可以運行在任何兼容J2SE-5.0環境下（如你的應用服務器），目前處于Beta版測試中。其他廠商同樣可以快速發布他們自己的可嵌入EJB 3.0產品，非凡是規范中“數據持久化”部分。
　　
　　另一方面，Spring一直是一個非標準的技術，而且在可以預計的未來仍將如此。盡管你在任何應用服務器都上可以使用Spring框架，但基于Spring的應用仍然被限制于Spring本身和在你的應用中使用到的Spring提供的各種非凡服務。
　　
　　由于Spring框架是一個開源項目，因此，它使用的配置文件XML格式和開發接口都是私有的。當然，這種限制不僅體現在Spring框架中，其他任何非標準產品都會有這種限制。但是，你的Spring應用的長期生存能力將依靠于Spring項目本身（或者說Interface 21公司，因為它雇傭了大多數的Spring核心開發人員）。并且，假如你使用了Spring提供的非凡服務，如Spring事務治理器或者Spring MVC，你同樣被限制于Spring提供的API。
　　
　　并且，Spring應用是知道后端服務提供者的（即應用程序是知道服務提供者的，這樣應用程序將會在一定程度上依靠于服務提供方：譯者注）。例如，對于數據持久化服務，Spring框架提供了不同的DAO和模板Helper類，用于JDBC、Hibernate,、iBatis和JDO。這樣，假如你需要改變一個Spring應用的持久化服務提供者（如，從JDBC換到Hibernate），你將需要重構你的系統應用代碼，來使用新的Helper類。
　　
　　服務整合
　　
　　Spring框架是建立在應用服務器和服務庫之上，它的服務整合代碼（如數據訪問模板和Helper類）是基于框架的，并暴露給應用開發者。相反，EJB 3.0框架是緊密整合到應用服務器中的，它的服務整合代碼是封裝在一個標準的接口下的。
　　
　　因此，EJB 3.0廠商可以輕松的優化整體性能和開發者體驗。如，在JBoss的EJB 3.0實現中，當你通過實體治理器持久化一個實體BEAN POJO時，Hibernate session事務將在JTA事務提交時自動提交。通過使用簡單的@PersistenceContext注解（例子參看后面文章），你可以甚至可以將實體治理器和其下的Hibernate事務綁定到一個有狀態的session bean上。應用程序事務可以在一個session中跨越多個線程，在事務性的WEB應用中這是非常有用的，如多頁面的購物車。
　　
　　基于EJB 3.0 框架、Hibernate、和JBoss 內部Tomcat的緊密整合，上面提到的簡單的整合的編程接口是可能的。Oracle的EJB 3.0框架和它內部的Toplink持久服務可以達到同樣層次的整合。
　　
　　EJB 3.0中整合服務的另一個好例子是集群支持。假如你部署一個EJB 3.0應用到一個集群服務器，所有的故障切換、負載均衡、分布式緩存、和狀態復制服務對于應用程序來說，都是自動完成的。集群服務被隱藏在EJB 3.0編程接口之下，對于EJB 3.0開發者來說，這些服務都是完全透明的。
　　
　　在Spring中，優化框架和服務之間交互更加困難一些。例如，想要用Spring的聲明式事務服務來治理Hibernate事務，必須在XML配置文件中明確的配置Spring的事務治理器（TransactionManager）和Hibernate SessionFactory對象。Spring應用開發者必須自己治理跨越多個HTTP請求的事務。并且，沒有簡單的方法可以在Spring應用中實現集群服務
　　
　　服務聚合的靈活性
　　
　　由于Spring中的服務整合代碼是作為編程接口暴露給應用開發者的，因此開發人員可以根據需要來聚合多個服務。這個特性使你可以集成一個你自己的“輕量”級應用服務器。Spring的一個通常的用法是將Tomcat和Hibernate連接起來來支持簡單的數據庫驅動的WEB應用程序。在這種情況下，Spring本身提供了事務治理服務，Hibernate提供了持久化服務，這種設置本身就創建了一個小型的應用服務器。
　　
　　通常，EJB 3.0應用服務器不提供給開發者這種按照你的需要來選擇服務的靈活性。大多數情況，你會得到一系列已經預先打包好的特性，其中有些你可能是不需要的。然而，假如應用服務器提供了模塊內部的獨特設計，就象JBOSS一樣，你可以不去關心這些不必要的特性。在任何情況下，去定制一個全功能的應用服務器并不是一個瑣碎而沒有意義的工作。
　　
　　當然，假如一個應用不是一個單一的結點，你將需要連接多個應用服務器提供的服務（如資源池、消息隊列和集群）。這種情況下，從總的資源消耗上看，Spring框架就和任何EJB 3.0方案一樣是“重量級”的。
　　
　　為了進行容器外的單元測試，Spring的靈活的服務聚合也可以來連接假對象，來替代真的服務對象。在EJB 3.0應用中，大多數的組件都是簡單POJO，他們可以輕易進行容器外的單元測試。但是，假如要測試與容器服務相關的服務對象（如持久化實體治理器），更好的方式是進行容器內的測試，因為這樣比使用假對象來替代的方式更加輕易，更加健壯，而且更加準確。
　　
　　XML vs. 注解
　　
　　從應用開發者的角度來看，Spring的編程接口主要基于XML配置文件，而EJB 3.0則大量的使用了JAVA注解。XML文件可以表達復雜的關系，但是它們更加冗長而且不健壯。注解的方式很簡單明了，但是很難去表達復雜的或者繼續性的結構。
　　
　　Spring和EJB 3.0分別選擇了XML和注解方式，這取決于框架的體系結構：由于注釋只能描述相當少的配置信息，只有一個預先整合好的框架（如大多數重要事情已經在框架中實現了）才能大量的使用注釋作為它的配置選項。象我們討論的一樣，EJB 3.0滿足了這些要求，而Spring作為一個一般的注射依靠框架，它沒有做到這一點。
　　
　　當然，由于EJB 3.0和Spring相互學習了很多特性，所以，它們都在某種層次上支持XML和注釋。例如，EJB 3.0中可以應用XML配置文件來作為一個選擇性的機制，用來改變注釋的默認行為。注釋也可以用來配置一些Spring服務。
　　
　　研究XML和注釋直接區別的最好的方式就是通過例子。在下面的幾節中，我們將一起看一下EJB 3.0和Spring是如何為應用程序提供要害服務的。
　　
　　聲明式服務
　　
　　EJB 3.0和Spring都將運行時服務（如事務治理、安全、日志、消息、和信息服務）連接給應用程序。由于這些服務同應用程序的業務邏輯并不是直接相關的，因此，它們不被應用程序本身來治理。相反，這些服務被服務容器（如EJB 3.0和Spring）以不可見的方式在運行時提供給應用程序。開發人員（或系統治理員）通過配置來告訴容器什么時候，以怎樣的方式來

上一篇：分享Spring中接口注入的三種方式

下一篇：Spring VS. HiveMind 優點缺點大比拼