J2EE開發框架發展簡史 開源框架的出現
Java2企業版為中間件領域思想的統一上發揮了很大的作用。比如，J2EE為分布式事務管理、目錄服務和消息服務提供了一套標準的編程接口。J2EE的基礎——Java2標準版(J2SE) ，成功地為Java提供了一套訪問關系數據庫的標準。
但是，就像本文中“J2EE缺乏對編程的支持”提到的一樣，J2EE這個平臺沒有能夠提供一個令人滿意的應用程序編程模型（application programming model）。
Sun公司和一些大的應用服務器供應商都想用開發工具來降低J2EE開發的復雜性，但是這些工具沒有其他的JAVA 開發工具優秀，后者有先進的重構工具，和.NET平臺相比，J2EE的工具支持顯得很遜色。
很多J2EE開發工具自動產生的代碼像這些工具本身同樣復雜。在開源社區很多小型J2EE開發者選擇了另外一種開發方式—— 一些可以降低J2EE開發難度的開發框架,較為流行的比如：Struts, Hibernate, 和 Spring 架構，他們在當今很多J2EE項目中扮演著重要角色。
為什么要采用框架？
框架是由一些類組成，正是這些類為應用程序提供了一個可重用的設計，或者我們經常提到的，應用程序中的一層。應用程序代碼訪問類庫從而執行任務，而框架是調用應用程序代碼，從而管理程序的流程。這就是經常說道的好萊塢原則：“不要試圖聯系我們，我們到時候自會通知你?！遍_發者寫的程序在運行時由框架調用。
設計一個在各種未知背景下都可以使用的框架是很有挑戰性的。框架很適合在復雜的J2EE開發中使用，它可以為開發者提供一個簡單易用的模型。
采用一個經過良好設計的開源框架有很多好處：
◆在好的框架下，開發者只需要寫一些必須的代碼；他們不需要直接接觸底層的API。 這一點很重要。
◆經過良好設計的框架可以為程序提供清晰的結構并且提高程序的內聚性。好清晰的結構使得其他人可以更容易加入項目。
◆一個容易使用的框架可以通過一些例子和文檔為用戶提供最佳實踐。
◆采用成功的框架的代碼比自己的代碼容易測試
◆框架只有提供了一些值得使用的功能才會變得流行。J2EE工程只有真正需要框架的時候才會用它，而自己的框架并不是這樣，后者是處于統治地位的。
J2EE本身也提供了一些框架。比如， Enterprise Java-Beans (EJB) container或者 Servlet engine，二者都運用了“ 采用了好萊塢原則”這個思想，并采用運行時調用來管理對象。像Struts這些開源web應用框架正是建立在這兩個框架的基礎上的，本文討論的重點也是像Struts這樣建立在J2EE上的開發框架，他們為開發者提供了更為簡單的模型，和其他的一些好處。
開源框架的出現
很多大型的J2EE項目都用自己的內部框架來隱藏平臺的復雜性，直到最近人們才逐漸發現一些在很多項目中都存在的共有的難題，這些難題都可以由一個較為統一的解決方案來解決。而有的框架正好可以充當這些問題的解決方案?，F在有種很明顯的趨勢：與從前的內部框架相比，這些框架將成為這些難題的更加“標準化 ”的解決方案。
J2EE平臺的日益成熟是這些框架流行的一個原因。開發者知道有些地方是J2EE的標準API無能為力的，依他們的經驗來看，要彌補這個缺陷是很困難的。與此同時，一些優秀的開源框架可供使用，它們提供了極為豐富的技術文檔，在它們背后還有一個專業的團隊做支持，并且一切都是免費的。
Struts
Struts，在web應用程序產生時就有的開源框架。在1999－2000年，開發者們意識到JSP“Model1”的缺陷，JSP中充斥著請求處理代碼和靜態數據模板，這意味著你不得不把業務邏輯和復雜的HTML以及其他的標簽混到一起。
那個時候還沒有標準的框架和J2EE的標準支持，要解決這個問題開發者就得自己實現前端控制器，這樣可以把業務邏輯分離到java類中，從而可以減輕對JSP的維護難度。
前端控制器模式經常運用在MVC架構中，MVC模式在OO語言的GUI開發中經常使用（這個名字總是讓人誤解，WEB MVC中的視圖是從模型中“拉”數據；而在經典MVC中，模型把事件“推向”視圖）。
最初的前端控制器實現質量參差不齊。2001～2002年間，Apache開源組織(http://struts.apache.org)發布的Struts改變了這個狀況，雖然它并非一個完美的框架，但已經足夠使其成為該領域事實上的標準。
Struts向人們展示了開源框架的一些優點，比如，新手可以很容易地熟悉它的結構。2002年末，它成立很多J2EE項目很自然的選擇，每一個認真的J2EE開發者都會對它很熟悉。
Struts幾乎用在每一個J2EE項目中，這使得它成為J2EE架構的一個重要組成部分。甚至很多保守的組織也將其作為軟件底層的一部分，并同意接受Apache的開源協議條款。
Hibernate
下一個倒下的多骨諾米牌就是持久化。J2EE提供了兩個持久化的手段：JDBC，它是J2SE中訪問關系數據庫系統的標準API；另一個是實體Beans ,它是EJB中專門模型化持久化實體的組件。
JDBC以一種錯誤的編程模型來強制開發者用Java代碼來處理關系思想。而實體beans，先不說Sun和其他主要的J2EE供應商的吹噓，給人很笨重的感覺：起初這門技術的應用范圍很窄，連持久對象間的關系都不能處理。它使得應用程序難于測試，并且使用了一個很糟糕的查詢語言。直到2003年，即使EJB2.0和2.1做了很多改進，開發者們卻很少用它。
早期的嘗試。持久化問題的解決方案是由關系-對象映射（ORM）來解決的，它可以透明地持久化普通java對象（POJO）。該思想在注釋中有解釋。雖然這種方案并不是專屬java的。但相對與其他的社區而言比如.NET，ORM在java社區更加流行(.NET開發者總是對之抱有懷疑的態度)。
【編輯推薦】
