J2EE開發(fā)框架

Rod Johnson

Java2企業(yè)版為中間件領域思想的統(tǒng)一上發(fā)揮了很大的作用。比如，J2EE為分布式事務管理、目錄服務和消息服務提供了一套標準的編程接口。J2EE的基礎——Java2標準版(J2SE) ，成功地為Java提供了一套訪問關系數(shù)據(jù)庫的標準。

但是，就像本文中“J2EE缺乏對編程的支持”提到的一樣，J2EE這個平臺沒有能夠提供一個令人滿意的應用程序編程模型（application programming model）。Sun公司和一些大的應用服務器供應商都想用開發(fā)工具來降低J2EE開發(fā)的復雜性，但是這些工具沒有其他的JAVA 開發(fā)工具優(yōu)秀，后者有先進的重構工具，和.NET平臺相比，J2EE的工具支持顯得很遜色。

很多J2EE開發(fā)工具自動產(chǎn)生的代碼像這些工具本身同樣復雜。在開源社區(qū)很多小型J2EE開發(fā)者選擇了另外一種開發(fā)方式—— 一些可以降低J2EE開發(fā)難度的開發(fā)框架,較為流行的比如：  Struts, Hibernate, 和 Spring Framework，他們當今很多J2EE項目種扮演著重要角色。

為什么要采用框架？

框架是一由一些類組成，正式這些類為應用程序提供了一個可重用的設計――或者我們經(jīng)常提到的——應用程序種的一層。應用程序代碼訪問類庫從而執(zhí)行任務，而框架是調(diào)用應用程序代碼，從而管理程序的流程。這就是經(jīng)常說道的好萊塢原則：“不要試圖聯(lián)系我們，我們到時候自會通知你。”開發(fā)者寫的程序在運行時由框架調(diào)用。

設計一個在各種未知背景下都可以使用的框架是很有挑戰(zhàn)性的?？蚣芎苓m合在復雜的J2EE開發(fā)中使用，它可以為開發(fā)者提供一個簡單易用的模型。采用一個經(jīng)過良好設計的開源框架有很多好處：

Ÿ           在好的框架下，開發(fā)者只需要寫一些必須的代碼；他們不需要直接接觸底層的API。  這一點很重要。

Ÿ           經(jīng)過良好設計的框架可以為程序提供清晰的結構并且提高程序的內(nèi)聚性。好清晰的結構使得其他人可以更容易加入項目。

Ÿ           一個容易使用的框架可以通過一些例子和文檔為用戶提供最佳實踐。

Ÿ           采用成功的框架的代碼比自己的代碼容易測試

Ÿ           框架只有提供了一些值得使用的功能才會變得流行。J2EE工程只有真正需要框架的時候才會用它，而自己的框架并不是這樣，后者是處于統(tǒng)治地位的。

J2EE本身也提供了一些框架。比如， Enterprise Java-Beans (EJB) container或者 Servlet engine，二者都運用了“ 采用了好萊塢原則”這個思想，并采用運行時調(diào)用來管理對象。像Struts這些開源web應用框架正式建立在這兩個框架的基礎上的，本文討論的重點也是像Struts這樣建立在J2EE上的框架，他們?yōu)殚_發(fā)者提供了更為簡單的模型，和其他的一些好處。

開源框架的出現(xiàn)。

很多大型的J2EE項目都用自己的內(nèi)部框架來隱藏平臺的復雜性，直到最近人們才逐漸發(fā)現(xiàn)一些在很多項目中都存在的共有的難題，這些難題都可以由一個較為統(tǒng)一的解決方案來解決。而有的框架正好可以充當這些問題的解決方案?，F(xiàn)在有種很明顯的趨勢：與從前的內(nèi)部框架相比，這些框架將成為這些難題的更加“標準化 ”的解決方案。

J2EE平臺的日益成熟是這些框架流行的一個原因。開發(fā)者知道有些地方是J2EE的標準API無能為力的，倚他們的經(jīng)驗來看，要彌補這個缺陷是很困難的。于此同時，一些優(yōu)秀的開源框架可供使用，它們提供了極為豐富的技術文檔，在它們背后還有一個專業(yè)的團隊做支持，并且一切都是免費的。

Struts。在web應用程序產(chǎn)生的那時就有了開源框架。在1999－2000年，開發(fā)者們意識到JSP“Model1”的缺陷，JSP中充斥著請求處理代碼和靜態(tài)數(shù)據(jù)模板，這意味著你不得不把業(yè)務邏輯和復雜的HTML以及其他的標簽混到一起。那個時候還沒有標準的框架和J2EE的標準支持，要解決這個問題開發(fā)者就得自己實現(xiàn)前端控制器，這樣可以把業(yè)務邏輯分離到java類中，從而可以減輕對JSP的維護難度。前端控制器模式經(jīng)常運用在MVC架構中，MVC模式在OO語言的GUI開發(fā)中經(jīng)常使用（這個名字總是讓人誤解，WEB MVC中的視圖是從模型中“拉”數(shù)據(jù)；而在經(jīng)典MVC中，模型把事件“推向”視圖）。

最初的前端控制器實現(xiàn)質(zhì)量參差不齊。2001～2002年間，Apache開源組織發(fā)布的Struts改變了這個狀況，雖然它并非一個完美的框架，但已經(jīng)足夠使其成為該領域事實上的標準。

Struts向人們展示了開源框架的一些優(yōu)點，比如，新手可以很容易地熟悉它的結構。2002年末，它成立很多J2EE項目很自然的選擇，每一個認真的J2EE開發(fā)者都會對它很熟悉。

Struts幾乎用才每一個J2EE項目中，這使得它成為J2EE架構的一個重要組成部分。甚至很多保守的組織也將其作為軟件底層的一部分，并同意接受Apache的開源協(xié)議條款。

Hibernate。下一個倒下的多骨諾米牌就是持久化。J2EE提供了兩個持久化的手段：JDBC，它是J2SE中訪問關系數(shù)據(jù)庫系統(tǒng)的標準API；另一個是實體Beans ,它是EJB中專門模型化持久化實體的組件。

JDBC以一種錯誤的編程模型來強制開發(fā)者用Java代碼來處理關系思想。而實體beans，先不說Sun和其他主要的J2EE供應商的吹噓，給人很笨重的感覺：起初這門技術的應用范圍很窄，連持久對象間的關系都不能處理。它使得應用程序難于測試，并且使用了一個很糟糕的查詢語言。直到2003年，即使EJB2.0和2.0做了很多改進，開發(fā)者們卻很少用它。

早期的嘗試。

持久化問題的解決方案是由關系-對象映射（ORM）來解決的，它可以透明地持久化普通java對象（POJO）。該思想在注釋中有解釋。雖然這種方案并不是專屬java的。但相對與其他的社區(qū)而言比如.NET，ORM在java社區(qū)更加流行(.NET開發(fā)者總是對之抱有懷疑的態(tài)度)。

早在1990年，一些商業(yè)的ORM工具就出現(xiàn)了，比如TopLink。但由于其價格昂貴、結構復雜并且與Sun的實體bean標準相左，所以很少人會用。不管怎樣，在持久化POJO方面，這些工具與JDBC和實體Bean相比確實有了很大的進步

Java Data Object于2001年在Java Community Progress(www.)的規(guī)范中出現(xiàn)。它為一般的POJO提供了大多數(shù)的持久化實現(xiàn)(盡管很多實現(xiàn)都是對關系數(shù)據(jù)庫的)。但Sun公司以及其他的J2EE技術提供商對該技術表現(xiàn)的很冷淡。所以JDO也沒有能夠流行。

Hibernate的出現(xiàn)。ORM領域在2002年發(fā)生了大變化，原因有兩個。首先，實體Beans在實踐中失敗，開發(fā)者們將其從J2EE中忽視掉了。它向開發(fā)者們說明了一個規(guī)范是如何將開發(fā)拉入泥潭的。

另外的一個原因是Hibernate的發(fā)布，它是第一個功能健全的解決關系對象影射解決方案。雖然在功能上，它沒有TopLink多樣。但在那些最常用的功能上，Hibernate實現(xiàn)的更加健壯，并且有一個非常專業(yè)的團隊提供全職的開發(fā)。Hibernate并不是全新的，它的ORM思想在這個領域很普遍，但它提供的編程模型比其他任何競爭者都容易使用、都來的直接，它為ORM的使用提供了更加易用、廉價的途徑。

于此同時，新一代的商業(yè)產(chǎn)品針對關系數(shù)據(jù)庫提供了極其高效的JDO規(guī)范的實現(xiàn)。這樣開發(fā)者的選擇就更豐富了；還有，TopLink也朝著開發(fā)者友好的方向前進，它的liscense越來越開放了。

ORM大獲全勝。

所的這些因素是的ORM比以往更加規(guī)范。雖然很多項目仍然使用自己的持久層框架，但Hibernate，TopLink以及一些高端的JDO實現(xiàn)，使得使用自己持久層框架的難度相對變大、可維護性降低，自然，也沒有什么理由去使用自己的框架了。

雖然這些框架的功能覆蓋范圍已經(jīng)很大了，但仍有很多地方不在其中。比如，一個基于struts，hibernate的項目，業(yè)務邏輯很難搞定。盡管對于這種問題，J2EE規(guī)范提出了解決方案（EJB），但仍舊沒有一個合適的編程模型。

Spring

J2EE框架被大規(guī)模地運用到項目中，而項目總要負責這些框架以及自己業(yè)務代碼的連接，使之真正融合到一起。Spring就是專注于這個問題的，它和Hibernate融合的很好。

本質(zhì)上講，Spring是IOC(Inversion of Control)和面向切面編程(AOP)的組合體。它是一個非侵入式的框架，增強了POJO的功能。從服務上講(With a service abstraction)，它將程序代碼從J2EE環(huán)境解耦到普通的java對象（自然，這些代碼可以脫離J2EE而在多種環(huán)境中運行）。它還在很多功能上提供了除EJB之外的選擇――比如為所有的POJO提供聲明式事務。Spring被廣泛運用到很多項目中，從小的web程序到大的企業(yè)應用程序。

在這個領域還有其他的產(chǎn)品，比如HiveMind和NamoContainer。前者和Spring的思想大致相同，只不過在IOC上有較大差異；后者將很多服務融合在PicoContainer的IOC容器中。這些產(chǎn)品的實現(xiàn)方式和J2EE的不同在于，它們都很輕便。

在有J2EE API下做測試是非常困難的，這些容器將POJO從J2EE API中脫離出來，從而大大降低了測試的難度。測試一個普通的java對象，不用象測試J2EE程序那樣，得先將應用程序部署到服務器上，要不就得自己動手模擬J2EE環(huán)境。提供日益流行的測試驅動的開發(fā)環(huán)境（對于開發(fā)者來說這是應得的），是這些輕量容器流行的關鍵因素。

下一個將會是誰？

人們?nèi)找鎸﹂_源框架的重視，使得很多項目的成本大大降低，并且投放使用以及維護速度都增加了?，F(xiàn)在的開源框架都有很高的質(zhì)量，都提供了很好的文檔＆一些書籍讓開發(fā)者做參考。即便如此，兩大因素是的J2EE領域充滿了不確定性：開源領域和J2EE“標準”的沖突和AOP的日益重要。

開源和標準之間的沖突表現(xiàn)在兩個地方。一個是表現(xiàn)層，JSF的身后有Sun公司和其他的一些大公司，而在這個領域有Struts等開源產(chǎn)品與之競爭。在中間層，EJB 3.0采用J2SE5.0的annotations實現(xiàn)了依賴注入(dependency injection)的功能，但這個功能只是Spring的一個子集

在這兩個領域，開源產(chǎn)品都更加革新。JSP借鑒了ASP.NET，而Tapestry則采用了WebObjects的思想。

同樣的，不知道EJB3.0為何要嘗試著標準化依賴注入，即使這樣會使之不可避免地喪失很多功能。 EJB 3.0好像也要進入程序編寫領域，而J2EE規(guī)范在這方面還沒有涉足。

于此同時，AOP的重要性在J2EE社區(qū)猛增，在使用上，AOP也越來越受到開發(fā)者的青睞。像Spring、dynaop等被稱作“帶著雙拐的AOP”實現(xiàn)提升了AOP的知名度。而純粹的AOP技術比如AspectJ，在將來的幾年也會流行起來。

其次，JBoss通過JCP和EJB3.0保持一致，它極大地推動了AOP技術。但即使如此，JCP 還沒有轉向AOP跡象。

下一代的J2EE規(guī)范將擁抱更簡單的POJO編程模型，就像Spring和Hibernate做的一樣。J2EE開發(fā)者也注定要從“欺詐客戶”轉到以自己的編程經(jīng)驗開發(fā)上來。這次改變將受到大多數(shù)人的歡迎，不像以前那樣每一個新規(guī)范發(fā)布后，最終都沒有能很好的實現(xiàn)。

   本位作者Rod Johnson 是Interface21的CEO。該公司是位于倫敦的一家J2EE咨詢公司。他的聯(lián)系方式是：rod@interface21.com 。

   編輯 Richard G. Mathieu,他是St. Louis大學Decision Sciences and MIS部門主任，他的聯(lián)系方式： mathieur@slu.edu