表現層架構Struts/Tapestry/JSF比較

來源:互聯網
上載者:User
js|比較   Struts/Tapestry/JSF是目前J2EE表現層新老組合的架構技術。從誕生時間上看,Struts應該比較早,使用得非常廣泛,Tapestry 3.0逐漸引起廣泛的重視,正當Tapestry即將大顯身手時期,SUN推出JSF標準技術,雖然JSF一開始推出尚不成熟,留出了一段空白期,但是隨著JSF1.1標準推出,JSF開始正面出擊,粉面隆重登場了。

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

  首先,我們從一個高度來抽象一下表現層架構應有的技術架構,下圖可以說所有表現層架構技術都必須實現的功能架構圖:

  當然,我們不必廢話羅嗦MVC模式,MVC模式是基準模式,現在架構技術已經不必再拼是否是MVC模式了。 在上圖MVC模式基礎上,一個表現層架構無外乎要實現圖中的三個功能:

  1.在當前頁面能夠顯示一個組件對象的內容;而不是象純JSP那樣,需要在Jsp頁面寫入“調用對象方法”的Java代碼。

  2.當使用者按下頁面的提交按扭或連結後,事件發生,這時應該觸發伺服器端並將當前頁面的參數提交給伺服器。這種機製表現在Form表單提交和有參數的連結<a href=""></a>

  3.從一個整頁模式直接跳轉到另外一個整頁模式,單純的導航作用。

  我們通過下表來比較這 三種架構在實現上圖各個功能時技術細節,從而得出他們的異同點和偏重點。

  Struts Tapestry3.0 JSF
在View顯示的組件要求

組件必須繼承ActionForm

分顯式調用和隱式調用
組件必須繼承BaseComponent
普通POJO
無需繼承
Managed Bean
組件在View顯示粒度 View頁面只能顯示與表單對應的ActionForm,配置中Action ActionForm 頁面一般只能1:1:1關係。 可將組件嵌入頁面任何一行,對使用組件數量無限制。 同Tapestry
頁面分區tiles 使用Tiles標籤庫實現,需要另外tiles-def.xml設定檔 組件有自己的視圖頁面,通過調用組件即直接實現多個頁面組合。強大自然的頁面組合是其特點。 通過組件+標籤庫實現Subview,但如需重用Layout,還要結合Tiles.
頁面跳轉 使用標籤庫html:link中寫明目標URL,URL名稱需要對照設定檔的path命名,與組件Action耦合。 URL名稱是目標的組件名稱,不涉及URL和路徑等操作,方便穩固。 類似Struts,也需要在設定檔中尋找,與組件分離。
參數傳遞 使用html:link時傳遞參數超過一個以上處理麻煩。 直接調用組件,直接賦予參數,沒有參數個數限制 參數分離傳遞給組件
事件觸發 通過表單提交submit啟用,不能細化到表單裡欄位。 能夠給於表單每個欄位貼一個事件,事件組件必須實現PageListener介面 同Tapestry,事件組件必須實習ActionListener 介面

  Struts組件編程模型

  Struts實現組件編程時有一些複雜:經常為一個頁面中需要引入多個組件而頭疼,因為Struts中無法直接引入多個組件,必須繞一些圈子:

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

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

  2.手工將多個組件裝入request/session等scope中,然後根據其名稱在jsp中獲得。

  這兩個方法都有缺點: 第一種辦法經常一個ActionForm弄得面目全非,變成一個大雜燴,違反了OO指派封裝的原則;第2種辦法其實又回到jsp編程;

  第二種情況,如果這些組件必須有預先由不同的Action來處理,每個組件必須經過Action -->ActionForm流程,在這種情況下有兩種辦法:

  1.使用Tiles, 不同流程輸出到同一個頁面的不同地區。是一種平行處理方式。

  2. 對多個流程首尾相連,第一Action forward結果是第二個Action,最後輸出一個Jsp,在這個jsp中就可以使用前面多個流程的多個ActionForm了,這屬於串列方式。

  Struts組件模型缺點

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

  Struts標籤庫

  在Struts中,經常需要使用標籤庫來顯示組件ActionForm中內容,這就涉及到一個結合的問題,標籤庫是別人寫的,參考Struts的標籤庫用法,而組件是自己的,難度和麻煩就體現在這個結合點上。

  JSF基本思路和Struts差不多,只不過換了不同標籤庫,也需要標籤庫+組件的結合思考,不過因為組件這裡是萬用群組件,沒有什麼限制,所以這樣比Struts要輕鬆一些。

  Tapestry使用了組件庫概念替代了標籤庫,沒有標籤庫概念,這樣就沒有標籤庫和自己的組件需要結合的問題,都是組件的使用,組件中分Tapestry標準組件和自己定義的組件,這也是接觸了Jsp體系的人學習Tapestry面臨的一個思路轉換。

  具體以頁面跳轉為例子,頁面跳轉是靠連結<a href="目標"></a> 實現,連結是頁面經常使用的元素。

  Struts提供的html:link在頻繁使用就特別不方便,尤其在傳遞多個參數時:其中html:link的page值,是跳轉對方頁面或Action的path,這個path一般需要到struts-config.xml尋找Action的相應path,一旦設定檔path值修改,涉及到這個所有相關頁面都要修改。

  JSF將連結概念劃分兩個方面:導航性質和事件啟用,在導航方面還是需要到配置faces-config查詢Navigation的from-outcome的值。

  由於Tapestry沒有標籤庫概念,只有組件或頁面兩個概念,因此,連結跳轉目標要麼是組件,要麼是頁面,簡潔簡單,它沒有多餘的path概念,就是組件名,也就是對象名稱,組件名稱和path名稱合二為一。

  總結

  JSF在很大程度上類似Struts,而不是類似Tapestry,可以說是一種Struts 2.0,都是採取標籤庫+組件的形式,只是JSF的組件概念沒有象Struts那樣必須繼承ActionForm的限制;JSF在事件粒度上要細膩,不象Struts那樣,一個表單一個事件,JSF可以細化到表單中的每個欄位上。

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

  Struts/JSF則適合在一般的資料頁面錄入的系統中,對於Struts和JSF的選用,我目前個人觀點是:如果你是一個新的系統,可以直接從JSF開始;如果你已經使用Struts,不必轉換,如果需要切換,可以將JSF和Tapestry一起考慮。

  另外,JSF/Tapestry不只是支援Html,也支援多種用戶端語言如WML或XUI等。

  這三者之間關係:如果說Struts是左派;那Tapestry則是右派;而JSF則是中間派,中庸主義是SUN同盟一貫策略。

  當然,你也可以發表你在實踐中這三者任何一個的使用感受,以使得後來者有一個比較。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。