JavaEE5與Struts、Spring、Hibernate
因為 java 技術的開放性，因為 JCP 所給予開發人員的諸多選擇性，作為 java 的研發/愛好者，在進行項目開發的時候，必然會面對 java 世界中的諸多框架,struts,spring,hibernate/ibatis 或者 servlet,ejb 等等--諸多開源的或者 JCP 組織所制定的標準框架，面對如此至多的框架，開發者該做何選擇呢?
眾所周知，在 java EE5 規范正式發布之前，很多開源 framework 都非常出名，為人們喜愛并廣泛使用，如 Struts、Spring、Hibernate 等，這些開放源代碼的作品曾經一定程度上成為 Java 企業級應用開發事實上的標準。然而 2006 年 5 月，隨著 Java EE 5 規范的正式發布，隨著眾多廠商對 java EE5 規范的眾多產品或者技術的支持的推出，開源與標準之間的競爭不可避免的......
Java EE 5 的出現，可能是 J2EE 誕生以來比較重量級的一次震撼，規范發布至今已有半年之多，業界對 Java EE 5 的關注也變得越來越熱烈，google 一下“java ee”關鍵字，可以得到 500 多萬條相關紀錄，而從 Sun 網站上進行檢索(http://java.sun.com/javaee/overview/compatibility.jsp)，也可以看到專業廠商 已經迅速跟進，除 Sun 公司本身外，包括全球聞名的 SAP、金蝶 Apusic 等另三家，已經推出全面支持 Java EE 5 規范的應用服務器產品。
Java EE 5 包含 JSF 1.2、EJB 3.0 及 JAX-WS 2.0 等新功能，試圖解決 Java 企業級應用開發的簡便性、靈活性及易用性問題。在 Java EE 5 出現之前，很多開源框架(Open Source Framework)如雨后春筍般涌現，嘗試從某種角度或某些方面去解決“委員會”規范所未能顧及的應用開發問題，如 Web 開發中的關注分離問題(MVC)、業務模型實現問題(ORM)等等。很多開源 framework 都非常出名，為人們喜愛并廣泛使用，如 Struts、Spring、Hibernate 等，這些“江湖派”作品曾經一定程度上成為 Java 企業級應用開發事實上的標準。Java EE 5 的出現，是否會改變這種狀況？或者說，人們在重新選擇應用框架時，是否會優先考慮全新的 Java EE 5 技術？帶著這種疑問，筆者試圖進行簡單的技術比較，并輔于膚淺的評論，希望能夠拋磚引玉、借花獻佛，以娛大眾。
Struts vs. JSF
|
Struts </td> |
JSF </td> </tr> | ||||||||||||||||||||||||||||||||||||||||||||
|
MVC </td> |
支持 </td> |
支持 </td> </tr> | |||||||||||||||||||||||||||||||||||||||||||
|
POJO </td> |
支持 </td> </tr> | ||||||||||||||||||||||||||||||||||||||||||||
|
頁面流（Page Flow） </td> |
支持 </td> |
支持 </td> </tr> | |||||||||||||||||||||||||||||||||||||||||||
|
UI組件（UI Component） </td> |
支持 </td> </tr> </tbody> </table>MVC 是模型(Model)、視圖(View)、控制(Controller)分層的結構，通過分層來實現關注分離，減少傳統開發中常見并重復的工作。 Struts 和 JSF 均支持 MVC。Struts 對 MVC 支持的核心是 Controller，通過 Controller (一個共同的入口 Servlet)獲得 HTTP 請求，將 HTTP 參數傳入 ActionForm，然后將 ActionForm 傳給 Action 類。Struts 對 HTTP 請求只有一個事件處理 handler，當請求過來時，由相應 Action 返回結果給前端 Controller，并據此選擇如何進行導航。JSF 一般也采用一個前端 Controller (有些商用 JSF 能夠智能識別 JSF 請求，無需額外的 controller)，不過在 Controller 中做的工作跟 Struts Controller 截然不同，它負責觸發 JSF 頁面組件中的事件，用 Render 工具生成組件的展現，綁定來自 Model 的數據到組件等。可以看到，JSF 在在控制層更靈活，在視圖層支持 Render 工具的變換而生成靈活的展現，在模型層實現與框架的徹底分離，因而具有更高的靈活性。 POJO 是無格式 Java 對象(Plain Old Java Object)。POJO 與 AOP 結合被廣泛用于快速業務模型。Struts 設計的初衷主要是解決視圖和控制問題，并無過多關注模型的靈活性問題。Struts 中的 ActionForm 模型必須繼承自框架類，雖然可以通過定制類庫提供一些幫助類實現模型與框架無關，但本質上還是緊耦合于 JSP- and HTTP-centric 方法。JSF 提供了對 POJO 天然的良好支持，并支持通過 RAD 工具實現快速的業務模型生成，從而具有更高的生產力。 頁面導航的最大意義是幫助實現頁面的可視化開發，在 UI 界面上快速定義頁面流向。頁面導航分靜態導航和動態導航兩種，靜態導航是頁面直接流向另一頁面，動態導航是由特定動作或邏輯決定頁面的流向。Struts 和 JSF 均支持靜態和動態頁面導航。不過 Struts 中的導航規則是綁定到 Action 中的，那意味著可能需要對同一頁面中不同的 Action 做重復性的導航規則制定，而 JSF 導航可以跟 Action 無關，可以在頁面中不同組件的不同 Action 間共享相同的導航規則。 Struts 本身并不提供 UI 組件機制，而 JSF 則提供了完整的 UI 組件機制。通過 UI 組件的定制和重用，能夠極大地簡化開發，提升用戶體驗。商業化的產品則往往更進一步，提供強大易用的開發工具，實現 drag-and-drop 方式所見即所得的 Web UI 開發。 Spring vs. EJB 3.0
| |