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聯盟的一貫策略。
當然，你也 可以發表你在實踐中這三者任何一個的使用感受，以使得後來者有一個比較。
