摘 要 目前流行的Java企業(yè)應(yīng)用系統(tǒng)框架種類繁多，為了使開發(fā)人員正確選擇系統(tǒng)架構(gòu)從而提高Java企業(yè)應(yīng)用的開發(fā)效率，首先針對(duì)基于EJB和基于POJOs的較為流行的幾種框架分別進(jìn)行了概述，然后對(duì)這些框架從表現(xiàn)層、業(yè)務(wù)邏輯層和持久層的實(shí)現(xiàn)細(xì)節(jié)進(jìn)行了對(duì)比，總結(jié)了Java企業(yè)應(yīng)用系統(tǒng)框架選擇需要側(cè)重考慮因素，得到了基于EJB的框架和基于POJOs的框架分別適用的范圍。
關(guān)鍵詞 Java企業(yè)應(yīng)用系統(tǒng)框架；EJB3.0；Spring；Hibernate
引言 EJB的體系結(jié)構(gòu)是J2EE的基礎(chǔ)和核心，J2EE定義了整個(gè)標(biāo)準(zhǔn)的應(yīng)用開發(fā)體系結(jié)構(gòu)和一個(gè)部署環(huán)境，基于EJB的框架一度成為人們開發(fā)Java企業(yè)應(yīng)用的首選。隨著Java開源項(xiàng)目陣營(yíng)的發(fā)展壯大， 一些基于POJOs(Plan Old Java Objects)的開源框架被越來(lái)越廣泛地引入到Java企業(yè)應(yīng)用的開發(fā)中來(lái)。根據(jù)復(fù)雜程度人們習(xí)慣把前者稱為重量級(jí)框架，把后者稱為輕量級(jí)框架。Java企業(yè)應(yīng)用框架一般被劃分為三個(gè)層次：表現(xiàn)層、業(yè)務(wù)邏輯組件層和持久層。本文主要對(duì)目前企業(yè)應(yīng)用對(duì)應(yīng)于這三個(gè)層次的兩種類型的流行框架進(jìn)行了細(xì)節(jié)比較，最后針對(duì)Java企業(yè)應(yīng)用的系統(tǒng)框架選擇提出作者的觀點(diǎn)。
兩種類型框架概述 1、基于EJB的重量級(jí)框架
由于 EJB容器能夠很好的處理系統(tǒng)性能、事務(wù)機(jī)制、安全訪問權(quán)限以及分布式運(yùn)算等問題，基于EJB框架進(jìn)行開發(fā)能保證企業(yè)應(yīng)用平滑發(fā)展，而不是發(fā)展到一種規(guī)模就重新更換一套軟件系統(tǒng)，且可以保證開發(fā)人員將大部份精力集中在業(yè)務(wù)邏輯的開發(fā)上。采用EJB框架開發(fā)的企業(yè)應(yīng)用具有必須繼承或依賴EJB容器的特點(diǎn)。EJB充分考慮到了頂級(jí)大型項(xiàng)目的需求，使用它幾乎能解決企業(yè)級(jí)應(yīng)用涉及到的所有問題，相應(yīng)的基于EJB框架也是一個(gè)功能復(fù)雜的重量級(jí)框架。
J2EE1.4標(biāo)準(zhǔn)規(guī)定的EJB 2.1框架缺少設(shè)計(jì)且實(shí)現(xiàn)起來(lái)有些過于復(fù)雜。當(dāng)前J2EE5.0的新規(guī)范提出的EJB 3.0的目標(biāo)就是簡(jiǎn)化開發(fā)[1]，借鑒了一些基于POJO的思想，它相對(duì)于EJB2.1中兩個(gè)重要的變化分別是：一是使用了Java5中的程序注釋工具，注釋取代了過多的XML配置文件并且消除了嚴(yán)格組件模型需求；二是采用了基于Hibernate和TopLink思想的O/R Mapping模型。
J2EE5.0的新規(guī)范中定義企業(yè)應(yīng)用三個(gè)層次的標(biāo)準(zhǔn)實(shí)現(xiàn)為：表現(xiàn)層采用JSF（Java Server Face），JSF的開發(fā)流程的核心是事件驅(qū)動(dòng)，組件和標(biāo)簽的封裝程度非常高，很多典型應(yīng)用已經(jīng)不需要開發(fā)者去處理http。整個(gè)過程是通過IoC(依賴注入)[2]來(lái)實(shí)現(xiàn)的；業(yè)務(wù)組件層采用EJB3.0的Session Bean。EJB3.0允許開發(fā)者使用藕合松散的組件來(lái)開發(fā)應(yīng)用。這些組件通過自己發(fā)布的商業(yè)接口來(lái)耦合，不必像EJB 2.1規(guī)范定義的那樣一個(gè)Bean必須遵守的嚴(yán)格的組件模型，每一個(gè)EJB類必須從某一種抽象類中繼承，并為容器提供了回調(diào)的鉤子；持久層采用EJB3.0實(shí)體Bean持久化模型，吸收了Hibernate的一些思想采用O/R Mapping模式， EJBQL也有許多重要的改變。
2、基于POJOs的輕量級(jí)框架
在基于POJOs輕量級(jí)框架上開發(fā)的應(yīng)用程序無(wú)需依賴于EJB容器可獨(dú)立運(yùn)行，對(duì)應(yīng)于Java企業(yè)應(yīng)用三個(gè)層次的輕量級(jí)框架技術(shù)分別都得到了一定的發(fā)展，這三個(gè)層次流行的框架如下：
目前比較流行的開源表現(xiàn)層框架主要有Struts和Tapestry。Tapestry與Struts應(yīng)用框架不同的是，它是基于組件，而不是面向腳本語(yǔ)言（比如JSP和Velocity）的，組件是由一個(gè)定義文件(以XML的格式)、一個(gè)HTML模板、一個(gè)JAVA類構(gòu)成的；業(yè)務(wù)組件層輕量級(jí)解決方案也不少，包括Spring、Hivemind等。但是目前使用最為廣泛的還是Spring框架，Spring框架是一個(gè)基于IoC和AOP（面向方面編程）[3]的構(gòu)架。采用IoC使得它可以很容易的實(shí)現(xiàn)bean的裝配，提供了簡(jiǎn)潔的AOP并據(jù)此實(shí)現(xiàn)事務(wù)管理等，但是它不具備處理應(yīng)用分布式的能力。Spring的核心要點(diǎn)是：支持不綁定到特定J2EE服務(wù)的可重用業(yè)務(wù)和數(shù)據(jù)訪問對(duì)象。這樣的對(duì)象可以在不同J2EE環(huán)境（Web或EJB）、獨(dú)立應(yīng)用程序、測(cè)試環(huán)境之間重用；持久層框主要有Hibernate和各種JDO產(chǎn)品，以及iBATIS。Hibernate是一個(gè)開源的O/R Mapping框架，它對(duì)JDBC進(jìn)行了非常輕量級(jí)的對(duì)象封裝，可以應(yīng)用在任何使用JDBC的場(chǎng)合，可以在應(yīng)用EJB的J2EE框架中取代CMP，完成數(shù)據(jù)持久化的重任。iBATIS是一個(gè)簡(jiǎn)易的SQL Map工具，它是將手工編寫的在xml配置文件中的SQL語(yǔ)句映射成Java對(duì)象。
對(duì)應(yīng)于三個(gè)層次的框架比較 1、表現(xiàn)層框架比較
MVC設(shè)計(jì)模式不再是某一種表現(xiàn)層框架的特點(diǎn)而是這幾種框架的共性。Struts框架由于出現(xiàn)時(shí)間早，所以使用相對(duì)廣泛，它的社區(qū)非?；钴S，很容易找到很多現(xiàn)成的開源功能標(biāo)簽以供使用以及樣例程序可供參考。但是它的組件在頁(yè)面中顯示的粗粒度，以及框架類的限制在很多情況下會(huì)表現(xiàn)得過于死板，給表示層的開發(fā)會(huì)帶來(lái)一些額外的代碼開銷。JSF在很大程度上類似Struts，只是JSF的組件概念沒有象Struts那樣必須繼承ActionForm的限制，JSF在事件粒度上要比Struts細(xì)膩。JSF有的另外一個(gè)優(yōu)勢(shì)就是其身后有Sun公司和其他的一些大公司的支持。Tapestry是一個(gè)完全組件的框架，Tapestry的組件可以被套嵌并包裹其它組件，因此可以組合形成一個(gè)更大的組件或邏輯頁(yè)面。組件的行為模式為Web頁(yè)面編程提供了很大的方便，事件處理也方便很多。所以，如果做一個(gè)對(duì)頁(yè)面要求靈活度相當(dāng)高的系統(tǒng)就可以考慮選用Tapestry。
表1 三種框架的表現(xiàn)層功能技術(shù)細(xì)節(jié)比較
框架
|
Struts
|
Tapestry3.0
|
JSF
|
View組件實(shí)現(xiàn)模式
|
標(biāo)簽庫(kù)+組件，組件必須繼承ActionForm
|
完全組件，分顯式調(diào)用和隱式調(diào)用，組件必須繼承BaseComponent
|
標(biāo)簽庫(kù)+組件，普通POJO無(wú)需繼承
|
組件在View顯示粒度
|
View頁(yè)面只能顯示與表單對(duì)應(yīng)的ActionForm，配置中Action與 ActionForm與 頁(yè)面一般只能1:1:1關(guān)系。
|
可將組件嵌入頁(yè)面任何一行，對(duì)使用組件數(shù)量無(wú)限制。
|
同Tapestry
|
頁(yè)面跳轉(zhuǎn)
|
使用標(biāo)簽庫(kù)html:link中寫明目標(biāo)URL，URL名稱需要對(duì)照struts_config.xml配置文件中的path命名，與組件Action耦合。
|
URL名稱是目標(biāo)的組件名稱，不涉及URL和路徑等操作，方便穩(wěn)固。
|
類似Struts，也需要在配置文件中查找，與組件分離。
|
事件觸發(fā)
|
通過表單提交submit激活，不能細(xì)化到表單里字段。
|
能夠給于表單每個(gè)字段賦一個(gè)事件，事件組件必須實(shí)現(xiàn)PageListener接口
|
同Tapestry，事件組件必須實(shí)現(xiàn)ActionListener
|
2、業(yè)務(wù)組件層框架比較
EJB 2.1框架有些過于復(fù)雜了，有如下缺點(diǎn)：① EJB模型需要建立許多組件接口和實(shí)現(xiàn)許多不必要的回滾方法；②EJB的部署描述復(fù)雜而容易出錯(cuò)；③開發(fā)人員不能脫離EJB容器測(cè)試。對(duì)于以上缺點(diǎn)JCP (Java Community Process)制訂的EJB3.0標(biāo)準(zhǔn)框架做了相應(yīng)的改進(jìn)，該框架為所有主要的J2EE廠商支持。EJB3.0和Spring兩個(gè)框架結(jié)構(gòu)都有一個(gè)共同核心設(shè)計(jì)理念：將中間件服務(wù)傳遞給耦合松散的POJOs。
EJB3.0框架與應(yīng)用
服務(wù)器高度整合，服務(wù)整合代碼也包裝在一個(gè)標(biāo)準(zhǔn)接口后面。EJB框架一方面有成熟的EJB容器支持，基于EJB框架的企業(yè)應(yīng)用性能優(yōu)良；另一方面EJB容器設(shè)計(jì)因?yàn)榭紤]了多方面的功能，所以在其內(nèi)核上總是會(huì)顯得臃腫，這也是一種重量表現(xiàn)。不需要的東西存在肯定會(huì)影響效率，EJB不能根據(jù)項(xiàng)目需求對(duì)EJB整體包括EJB容器進(jìn)行可配置式的切割。
Spring框架處于應(yīng)用服務(wù)器和服務(wù)庫(kù)的上方，服務(wù)整合的代碼屬于框架，并暴露于應(yīng)用開發(fā)者。它與應(yīng)用服務(wù)器整合的能力相對(duì)EJB3.0要弱。但是Spring框架模塊的可分離配置體現(xiàn)了它優(yōu)于EJB3.0的靈活性。
表2 EJB和Spring框架的具體細(xì)節(jié)比較
框架
|
EJB2/EJB3
|
Spring Framework 1.x
|
靈活性(松耦合)
|
EJB3比EJB2更具靈活性，EJB3支持應(yīng)用系統(tǒng)POJO
|
支持應(yīng)用系統(tǒng)POJO，框架本身可分離配置
|
功能完整性
|
全面，支持異步JMS 分布式事務(wù)
|
較為全面。有自己的表現(xiàn)層和持久層模板，可支持異步
|
領(lǐng)域范圍
|
支持業(yè)務(wù)邏輯Session
|
不支持，需要開發(fā)者額外基于ThreadLocal編制代碼
|
IoC/AOP支持
|
EJB3支持IoC， JBoss等EJB3服務(wù)器支持AOP；基于業(yè)務(wù)組件的較粗粒度
|
基于JavaBeans類的細(xì)粒度支持AOP
|
單臺(tái)性能
|
一般，批量查詢等大數(shù)據(jù)量業(yè)務(wù)處理須小心，存在本地不透明缺陷。
|
一般，應(yīng)用程序可配置cache/Pool以提高性能
|
可伸縮性
|
可支持多臺(tái)服務(wù)器分布式計(jì)算。
|
不支持，可依靠EJB實(shí)現(xiàn)
|
開發(fā)效率
|
學(xué)習(xí)曲線長(zhǎng)，導(dǎo)致熟練掌握難。借助商業(yè)開發(fā)工具可加快熟練者的開發(fā)速度。
|
可挑選只適合自己的功能實(shí)現(xiàn)。相對(duì)EJB稍簡(jiǎn)單。
|
系統(tǒng)規(guī)模
|
EJB2適合大型系統(tǒng);EJB3適合中大型系統(tǒng)
|
適合中小型系統(tǒng)，可借助EJB支持中大型系統(tǒng)
|
3、持久層框架比較
容器管理持久性（CMP）是對(duì)EJB中Entity Bean進(jìn)行持久性管理的方式。EJB2.1 持久性模型過于復(fù)雜并且存在基礎(chǔ)缺陷[3]。EJB3.0持久層針對(duì)EJB2.1的缺陷做了相應(yīng)改進(jìn)，采用與Hibernate類似的機(jī)制。
Hibernate相對(duì)而言其基本優(yōu)勢(shì)如下：①Hibernate 使用 Java 反射機(jī)制而不是字節(jié)碼增強(qiáng)程序來(lái)實(shí)現(xiàn)透明性；②Hibernate的使用簡(jiǎn)單；③映射的靈活性很出色，它支持各種關(guān)系數(shù)據(jù)庫(kù)，從一對(duì)一到多對(duì)多的各種復(fù)雜關(guān)系。Hibernate 也有一些缺點(diǎn)，它限制所使用的對(duì)象模型 (例如，一個(gè)持久性類不能映射到多個(gè)表)。
使用iBATIS提供的O/R Mapping機(jī)制，對(duì)業(yè)務(wù)邏輯實(shí)現(xiàn)人員而言，面對(duì)的是純粹的Java對(duì)象，這一層與通過Hibernate 實(shí)現(xiàn)O/R Mapping 而言基本一致，而對(duì)于具體的數(shù)據(jù)操作，Hibernate 會(huì)自動(dòng)生成SQL 語(yǔ)句，而iBATIS則要求開發(fā)者編寫具體的SQL 語(yǔ)句。相對(duì)Hibernate等 “全自動(dòng)”O/R Mapping機(jī)制而言，iBATIS以SQL開發(fā)的工作量和數(shù)據(jù)庫(kù)移植性上的讓步，為系統(tǒng)設(shè)計(jì)提供了更大的自由空間。作為“全自動(dòng)”ORM 實(shí)現(xiàn)的一種有益補(bǔ)充，iBATIS的出現(xiàn)顯得別具意義。
企業(yè)應(yīng)用系統(tǒng)框架選擇 設(shè)計(jì)和性能是實(shí)際框架選擇的兩個(gè)基本點(diǎn)，善于平衡才是框架選擇的主要宗旨。輕量級(jí)框架和重量級(jí)框架解決問題的側(cè)重點(diǎn)是不同的。
輕量級(jí)框架側(cè)重于減小開發(fā)的復(fù)雜度，相應(yīng)的它的處理能力便有所減弱（如事務(wù)功能弱、不具備分布式處理能力），比較適用于開發(fā)中小型企業(yè)應(yīng)用。采用輕量框架一方面因?yàn)楸M可能的采用基于POJOs的方法進(jìn)行開發(fā)，使應(yīng)用不依賴于任何容器，這可以提高開發(fā)調(diào)試效率；另一方面輕量級(jí)框架多數(shù)是開源項(xiàng)目，開源社區(qū)提供了良好的設(shè)計(jì)和許多快速構(gòu)建工具以及大量現(xiàn)成可供參考的開源代碼，這有利于項(xiàng)目的快速開發(fā)。例如目前Tomcat+Spring+Hibernate已經(jīng)成為許多開發(fā)者開發(fā)J2EE中小型企業(yè)應(yīng)用偏愛的一種架構(gòu)選擇。隨著可供選擇的框架層出不窮，開發(fā)者可以根據(jù)需要對(duì)應(yīng)于企業(yè)應(yīng)用三個(gè)層次的輕量級(jí)框架選擇，本文第2節(jié)的內(nèi)容可供選擇參考。
而作為重量級(jí)框架EJB框架則強(qiáng)調(diào)高可伸縮性，適合與開發(fā)大型企業(yè)應(yīng)用。在EJB體系結(jié)構(gòu)中，一切與基礎(chǔ)結(jié)構(gòu)服務(wù)相關(guān)的問題和底層分配問題都由應(yīng)用程序容器或服務(wù)器來(lái)處理，且EJB容器通過減少數(shù)據(jù)庫(kù)訪問次數(shù)以及分布式處理等方式提供了專門的系統(tǒng)性能解決方案，能夠充分解決系統(tǒng)性能問題。
輕量級(jí)框架的產(chǎn)生并非是對(duì)重量級(jí)框架的否定，甚至在某種程度上可以說二者是互補(bǔ)的。輕量級(jí)框架在努力發(fā)展以開發(fā)具有更強(qiáng)大，功能更完備的企業(yè)應(yīng)用；而新的EJB規(guī)范EJB3.0則在努力簡(jiǎn)化J2EE的使用以使得EJB不僅僅是擅長(zhǎng)處理大型企業(yè)系統(tǒng)，也利用開發(fā)中小型系統(tǒng)，這也是EJB輕量化的一種努力。對(duì)于大型企業(yè)應(yīng)用以及將來(lái)可能涉及到能力擴(kuò)展的中小型應(yīng)用采用結(jié)合使用輕量級(jí)框架和重量級(jí)框架也不失為一種較好的解決方案。
總結(jié) 目前適用Java企業(yè)應(yīng)用的系統(tǒng)框架可謂百花齊放，各種框架都有長(zhǎng)短，選擇應(yīng)用系統(tǒng)框架時(shí)不可盲目的追求流行，首先需要明確所要實(shí)現(xiàn)的應(yīng)用系統(tǒng)的系統(tǒng)處理能力需求，然后在熟悉比較各種框架細(xì)節(jié)的基礎(chǔ)上從設(shè)計(jì)以及開發(fā)效率方面進(jìn)行考慮。本文旨在為系統(tǒng)框架選擇提供一個(gè)參考，限于篇幅本文只對(duì)其中的幾種框架做了比較，開發(fā)者可以根據(jù)需要對(duì)更多其他框架細(xì)節(jié)進(jìn)行比較。(轉(zhuǎn)載文章請(qǐng)保留出處：
Java家(www.javajia.com))
