，規范發(fā)布至今已有半年之多，業(yè)界對Java EE 5的關(guān)注也變得越來(lái)越熱烈，google一下“java ee”關(guān)鍵字，可以得到500多萬(wàn)條相關(guān)紀錄，而從Sun網(wǎng)站上進(jìn)行檢索（http://java.sun.com/javaee/overview/compatibility.jsp），也可以看到專(zhuān)業(yè)廠(chǎng)商已經(jīng)迅速跟進(jìn)，除Sun公司本身外，包括全球聞名的SAP、金蝶Apusic等另三家，已經(jīng)推出全面支持Java EE 5規范的應用服務(wù)器產(chǎn)品。
Java EE 5包含JSF 1.2、EJB 3.0及JAX-WS 2.0等新功能，試圖解決Java企業(yè)級應用開(kāi)發(fā)的簡(jiǎn)便性、靈活性及易用性問(wèn)題。在Java EE 5出現之前，很多開(kāi)源框架（Open Source Framework）如雨后春筍般涌現，嘗試從某種角度或某些方面去解決“委員會(huì )”規范所未能顧及的應用開(kāi)發(fā)問(wèn)題，如Web開(kāi)發(fā)中的關(guān)注分離問(wèn)題（MVC）、業(yè)務(wù)模型實(shí)現問(wèn)題（ORM）等等。很多開(kāi)源framework都非常出名，為人們喜愛(ài)并廣泛使用，如Struts、Spring、Hibernate等，這些“江湖派”作品曾經(jīng)一定程度上成為Java企業(yè)級應用開(kāi)發(fā)事實(shí)上的標準。Java EE 5的出現，是否會(huì )改變這種狀況？或者說(shuō)，人們在重新選擇應用框架時(shí)，是否會(huì )優(yōu)先考慮全新的Java EE 5技術(shù)？帶著(zhù)這種疑問(wèn)，筆者試圖進(jìn)行簡(jiǎn)單的技術(shù)比較，并輔于膚淺的評論，希望能夠拋磚引玉、借花獻佛，以?shī)蚀蟊姟?/div>
Struts vs. JSF
| | Struts | JSF |
| MVC | 支持 | 支持 |
| POJO | | 支持 |
| 頁(yè)面流（Page Flow ） | 支持 | 支持 |
| UI 組件（UI Component ） | | 支持 |
MVC是模型（Model）、視圖（View）、控制（Controller）分層的結構，通過(guò)分層來(lái)實(shí)現關(guān)注分離，減少傳統開(kāi)發(fā)中常見(jiàn)并重復的工作。Struts和JSF均支持MVC。Struts對MVC支持的核心是Controller，通過(guò)Controller（一個(gè)共同的入口Servlet）獲得HTTP請求，將HTTP參數傳入ActionForm，然后將ActionForm傳給Action類(lèi)。Struts對HTTP請求只有一個(gè)事件處理handler，當請求過(guò)來(lái)時(shí)，由相應Action返回結果給前端Controller，并據此選擇如何進(jìn)行導航。JSF一般也采用一個(gè)前端Controller（有些商用JSF能夠智能識別JSF請求，無(wú)需額外的controller），不過(guò)在Controller中做的工作跟Struts Controller截然不同，它負責觸發(fā)JSF頁(yè)面組件中的事件，用Render工具生成組件的展現，綁定來(lái)自Model的數據到組件等?？梢钥吹?，JSF在在控制層更靈活，在視圖層支持Render工具的變換而生成靈活的展現，在模型層實(shí)現與框架的徹底分離，因而具有更高的靈活性。
POJO是無(wú)格式Java對象（Plain Old Java Object）。POJO與AOP結合被廣泛用于快速業(yè)務(wù)模型。Struts設計的初衷主要是解決視圖和控制問(wèn)題，并無(wú)過(guò)多關(guān)注模型的靈活性問(wèn)題。Struts中的ActionForm模型必須繼承自框架類(lèi)，雖然可以通過(guò)定制類(lèi)庫提供一些幫助類(lèi)實(shí)現模型與框架無(wú)關(guān)，但本質(zhì)上還是緊耦合于JSP- and HTTP-centric方法。JSF提供了對POJO天然的良好支持，并支持通過(guò)RAD工具實(shí)現快速的業(yè)務(wù)模型生成，從而具有更高的生產(chǎn)力。
頁(yè)面導航的最大意義是幫助實(shí)現頁(yè)面的可視化開(kāi)發(fā)，在UI界面上快速定義頁(yè)面流向。頁(yè)面導航分靜態(tài)導航和動(dòng)態(tài)導航兩種，靜態(tài)導航是頁(yè)面直接流向另一頁(yè)面，動(dòng)態(tài)導航是由特定動(dòng)作或邏輯決定頁(yè)面的流向。Struts和JSF均支持靜態(tài)和動(dòng)態(tài)頁(yè)面導航。不過(guò)Struts中的導航規則是綁定到Action中的，那意味著(zhù)可能需要對同一頁(yè)面中不同的Action做重復性的導航規則制定，而JSF導航可以跟Action無(wú)關(guān)，可以在頁(yè)面中不同組件的不同Action間共享相同的導航規則。
Struts本身并不提供UI組件機制，而JSF則提供了完整的UI組件機制。通過(guò)UI組件的定制和重用，能夠極大地簡(jiǎn)化開(kāi)發(fā)，提升用戶(hù)體驗。商業(yè)化的產(chǎn)品則往往更進(jìn)一步，提供強大易用的開(kāi)發(fā)工具，實(shí)現drag-and-drop方式所見(jiàn)即所得的Web UI開(kāi)發(fā)。
Spring vs. EJB 3.0
| | Spring | EJB3 |
| 標準（Standard ） | | 是，Java EE 5標準組成部分 |
| 持久（Persistence ） | JDBC, Hibernate, JDO, iBatis and JPA（ongoing spring 2.0） | JPA |
| 聲明式服務(wù)（Declarative Services ） | 支持 | 支持 |
| 依賴(lài)注入（Dependency Injection ） | 支持 | 支持 |
| 集群（Cluster ） | | 支持 |
Spring框架是一個(gè)開(kāi)源項目，并不是一個(gè)標準的東西。Spring自己定義了一套XML配置文件大綱以及程序接口，從長(cháng)遠考慮，有很大的不確定性。Spring的主要開(kāi)發(fā)者來(lái)自Interface21公司（這是幫我非常敬重的人），Interface21靠相關(guān)咨詢(xún)和服務(wù)維持，作為一個(gè)商業(yè)團體其利益取向將可以完全左右Spring未來(lái)的方向。相比EJB 3出身名門(mén)正派的標準血統并有眾多主流商業(yè)廠(chǎng)商支持，Spring的非標準性將可能帶來(lái)極大的風(fēng)險。
Spring框架本身不帶持久實(shí)現，但它支持JDBC, Hibernate, JDO和 iBatis等持久化框架。Spring通過(guò)使用不同的DAO和Helper類(lèi)以利用JDBC、Hibernate、iBatis或JDO，所以并沒(méi)有實(shí)現和最終服務(wù)提供者的隔離。簡(jiǎn)單來(lái)說(shuō)，就是需要重構代碼才能實(shí)現持久化框架的更換。EJB 3.0的持久集成在應用服務(wù)中，通過(guò)JPA，可以在底層更換持久實(shí)現，如將Hibernate更換為T(mén)oplink。EJB 3.0的持久具有更大的靈活性，并有利于廠(chǎng)商進(jìn)行性能優(yōu)化和擴展。
Spring和EJB3.0都為企業(yè)應用提供運行時(shí)服務(wù)，（如：事務(wù)、安全、日志消息、配置服務(wù)）。由于這些服務(wù)都不是直接與應用的業(yè)務(wù)邏輯相關(guān)聯(lián)，所以都不是由應用來(lái)自行管理。EJB3.0使用Java注釋來(lái)配置聲明式服務(wù)，Spring使用XML配置文件。在大多數情況下，EJB3.0的注釋聲明顯得更為簡(jiǎn)單和優(yōu)雅。Spring使用XML來(lái)定義屬性并配置聲明式服務(wù)的結果將是一個(gè)冗長(cháng)而不穩定的配置文件。
依賴(lài)注入模式（DI）是在應用中實(shí)現松散耦合的最佳實(shí)踐。Spring和EJB3.0都支持DI模式，但他們有著(zhù)深刻的不同。Spring支持通用的（但復雜的）基于XML配置文件的依賴(lài)注入API。EJB3.0支持注入大多數服務(wù)對象（如EJB和上下文對象）和通過(guò)簡(jiǎn)單注釋聲明的JNDI對象。
EJB 3.0完全支持集群。部署在服務(wù)集群中的EJB3.0應用將自動(dòng)獲得負載均衡、分布緩存、狀態(tài)復制等功能。底層的集群服務(wù)隱藏在EJB3.0編程接口后面，屏蔽了所有的復雜性。Spring沒(méi)有簡(jiǎn)單的利用集群的方法。
Hibernate vs. EJB 3.0
ibernate與EJB 3.0其實(shí)并沒(méi)有很好的可比性，因Hibernate僅關(guān)注ORM，而 EJB 3.0更多則更多表現為一種組件框架，其中包含ORM部分而已。EJB 3.0在設計過(guò)程中，曾經(jīng)得益于Hibernate的作者Gavin King，據說(shuō)EJB 3.0 EntityBean的設計理念完全來(lái)自于Hibernate。只需用將EJB 3.0 EntityBean API調用轉換為Hibernate API，Hibernate就可以成為EJB 3.0中EntityBean的 Implementation。
當開(kāi)源framework已經(jīng)成為習慣性勢力，并給人們帶來(lái)眾多樂(lè )趣或疲憊感的時(shí)候，Java EE 5的出現會(huì )是適逢其時(shí)嗎？無(wú)論如何，是繼續選擇開(kāi)源還是擁抱Java EE 5？相信今天這并不是個(gè)容易的選擇，或許，隨著(zhù)更多的廠(chǎng)商發(fā)布支持Java EE 5的產(chǎn)品，提供更好的工具支持，這個(gè)答案才會(huì )明朗起來(lái)。
