表現(xiàn)層框架Struts/Tapestry/JSF架構(gòu)比較

板橋里人 http://www.jdon.com 2005/09/12

　　Struts/Tapestry/JSF是目前J2EE表現(xiàn)層新老組合的框架技術(shù)。從誕生時間上看，Struts應(yīng)該比較早，使用得非常廣泛，Tapestry 3.0逐漸引起廣泛的重視，正當(dāng)Tapestry即將大顯身手時期，SUN推出JSF標(biāo)準(zhǔn)技術(shù)，雖然JSF一開始推出尚不成熟，留出了一段空白期，但是隨著JSF1.1標(biāo)準(zhǔn)推出，JSF開始正面出擊，粉面隆重登場了。

　　其實，JSF和Tapestry也并不是那種頭碰頭的相同競爭性技術(shù)，兩者還是各有側(cè)重點的，不過比較細微，但是這種細微點在實現(xiàn)一個大工程時可能帶來不同的感受和變化。

　　首先，我們從一個高度來抽象一下表現(xiàn)層框架應(yīng)有的技術(shù)架構(gòu)，下圖可以說所有表現(xiàn)層框架技術(shù)都必須實現(xiàn)的功能架構(gòu)圖：

　　當(dāng)然，我們不必廢話羅嗦MVC模式，MVC模式是基準(zhǔn)模式，現(xiàn)在框架技術(shù)已經(jīng)不必再拼是否是MVC模式了。 在上圖MVC模式基礎(chǔ)上，一個表現(xiàn)層框架無外乎要實現(xiàn)圖中的三個功能：

1.在當(dāng)前頁面能夠顯示一個組件對象的內(nèi)容；而不是象純JSP那樣，需要在Jsp頁面寫入“調(diào)用對象方法”的Java代碼。

2.當(dāng)用戶按下頁面的提交按扭或鏈接后，事件發(fā)生，這時應(yīng)該觸發(fā)服務(wù)器端并將當(dāng)前頁面的參數(shù)提交給服務(wù)器。這種機制表現(xiàn)在Form表單提交和有參數(shù)的鏈接<a href=""></a>

3.從一個頁面視圖直接跳轉(zhuǎn)到另外一個頁面視圖，單純的導(dǎo)航作用。

我們通過下表來比較這 三種框架在實現(xiàn)上圖各個功能時技術(shù)細節(jié)，從而得出他們的異同點和偏重點。

? Struts Tapestry3.0 JSF 在View顯示的組件要求 組件必須繼承ActionForm 分顯式調(diào)用和隱式調(diào)用 組件必須繼承BaseComponent 普通POJO 無需繼承 Managed Bean 組件在View顯示粒度 View頁面只能顯示與表單對應(yīng)的ActionForm，配置中Action ActionForm 頁面一般只能1:1:1關(guān)系。 可將組件嵌入頁面任何一行，對使用組件數(shù)量無限制。 同Tapestry 頁面分區(qū)tiles 使用Tiles標(biāo)簽庫實現(xiàn)，需要另外tiles-def.xml配置文件 組件有自己的視圖頁面，通過調(diào)用組件即直接實現(xiàn)多個頁面組合。強大自然的頁面組合是其特點。 通過組件+標(biāo)簽庫實現(xiàn)Subview,但如需重用Layout,還要結(jié)合Tiles. 頁面跳轉(zhuǎn) 使用標(biāo)簽庫html:link中寫明目標(biāo)URL，URL名稱需要對照配置文件的path命名,與組件Action耦合。 URL名稱是目標(biāo)的組件名稱，不涉及URL和路徑等操作，方便穩(wěn)固。 類似Struts，也需要在配置文件中查找,與組件分離。 參數(shù)傳遞 使用html:link時傳遞參數(shù)超過一個以上處理麻煩。 直接調(diào)用組件，直接賦予參數(shù)，沒有參數(shù)個數(shù)限制 參數(shù)分離傳遞給組件 事件觸發(fā) 通過表單提交submit激活，不能細化到表單里字段。 能夠給于表單每個字段貼一個事件，事件組件必須實現(xiàn)PageListener接口 同Tapestry，事件組件必須實習(xí)ActionListener 接口

Struts組件編程模型

　　Struts實現(xiàn)組件編程時有一些復(fù)雜：經(jīng)常為一個頁面中需要引入多個組件而頭疼，因為Struts中無法直接引入多個組件，必須繞一些圈子:

　　一般分兩種情況：如果同一個Action就可以對付這些組件，那么在這種情況下有兩個辦法：

1.將這多個組件裝入一個ActionForm中，如使用MapForm等機制；

2.手工將多個組件裝入request/session等scope中，然后根據(jù)其名稱在jsp中獲得。

　　這兩個方法都有缺點： 第一種辦法經(jīng)常一個ActionForm弄得面目全非，變成一個大雜燴，違反了OO分派封裝的原則；第2種辦法其實又回到j(luò)sp編程；

　　第二種情況，如果這些組件必須有預(yù)先由不同的Action來處理，每個組件必須經(jīng)過Action -->ActionForm流程，在這種情況下有兩種辦法：

1.使用Tiles, 不同流程輸出到同一個頁面的不同區(qū)域。是一種并行處理方式。

2. 對多個流程首尾相連，第一Action forward結(jié)果是第二個Action，最后輸出一個Jsp，在這個jsp中就可以使用前面多個流程的多個ActionForm了，這屬于串行方式。

Struts組件模型缺點

　　Struts組件編程必須限定在Action/ActionForm/JSP這三個框框中做文章，難度相對比較大，而Tapestry/JSF則沒有太多這些技術(shù)框框限制，兩者在組件編程方面更讓編程者自由一些，方便一些，這也是組件型框架的優(yōu)勢吧。

Struts標(biāo)簽庫

　　在Struts中，經(jīng)常需要使用標(biāo)簽庫來顯示組件ActionForm中內(nèi)容，這就涉及到一個結(jié)合的問題，標(biāo)簽庫是別人寫的，參考Struts的標(biāo)簽庫用法，而組件是自己的，難度和麻煩就體現(xiàn)在這個結(jié)合點上。

　　JSF基本思路和Struts差不多，只不過換了不同標(biāo)簽庫，也需要標(biāo)簽庫+組件的結(jié)合思考，不過因為組件這里是通用組件，沒有什么限制，所以這樣比Struts要輕松一些。

　　Tapestry使用了組件庫概念替代了標(biāo)簽庫，沒有標(biāo)簽庫概念，這樣就沒有標(biāo)簽庫和自己的組件需要結(jié)合的問題，都是組件的使用，組件中分Tapestry標(biāo)準(zhǔn)組件和自己定義的組件，這也是接觸了Jsp體系的人學(xué)習(xí)Tapestry面臨的一個思路轉(zhuǎn)換。

　　具體以頁面跳轉(zhuǎn)為例子，頁面跳轉(zhuǎn)是靠鏈接<a href="目標(biāo)"></a> 實現(xiàn)，鏈接是頁面經(jīng)常使用的元素。

　　Struts提供的html:link在頻繁使用就特別不方便，尤其在傳遞多個參數(shù)時：其中html:link的page值，是跳轉(zhuǎn)對方頁面或Action的path，這個path一般需要到struts-config.xml查找Action的相應(yīng)path,一旦配置文件path值修改，涉及到這個所有相關(guān)頁面都要修改。

　　JSF將鏈接概念劃分兩個方面：導(dǎo)航性質(zhì)和事件激活，在導(dǎo)航方面還是需要到配置faces-config查詢Navigation的from-outcome的值。

　　由于Tapestry沒有標(biāo)簽庫概念，只有組件或頁面兩個概念，因此，鏈接跳轉(zhuǎn)目標(biāo)要么是組件，要么是頁面，簡潔簡單，它沒有多余的path概念，就是組件名，也就是對象名稱，組件名稱和path名稱合二為一。

總結(jié)

　　JSF在很大程度上類似Struts，而不是類似Tapestry，可以說是一種Struts 2.0，都是采取標(biāo)簽庫+組件的形式，只是JSF的組件概念沒有象Struts那樣必須繼承ActionForm的限制；JSF在事件粒度上要細膩，不象Struts那樣，一個表單一個事件，JSF可以細化到表單中的每個字段上。

　　JSF只有在組件和事件機制這個概念上類似Tapestry，但是不似Tapestry那樣是一個完全組件的框架，所以，如果你做一個對頁面要求靈活度相當(dāng)高的系統(tǒng)，選用Tapestry是第一考慮。

　　Struts/JSF則適合在一般的數(shù)據(jù)頁面錄入的系統(tǒng)中，對于Struts和JSF的選用，我目前個人觀點是：如果你是一個新的系統(tǒng)，可以直接從JSF開始；如果你已經(jīng)使用Struts，不必轉(zhuǎn)換，如果需要切換，可以將JSF和Tapestry一起考慮。

　　另外，JSF/Tapestry不只是支持Html，也支持多種客戶端語言如WML或XUI等。

　　這三者之間關(guān)系：如果說Struts是左派；那Tapestry則是右派；而JSF則是中間派，中庸主義是SUN聯(lián)盟的一貫策略。