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

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

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

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

　　2.當用戶按下頁面的提交按扭或鏈接后，事件發生，這時應該觸發服務器端并將當前頁面的參數提交給服務器。這種機制表現在Form表單提交和有參數的鏈接<a href=""></a>

　　3.從一個頁面視圖直接跳轉到另外一個頁面視圖，單純的導航作用。

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

組件必須繼續ActionForm

　　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則沒有太多這些技術框框限制，兩者在組件編程方面更讓編程者自由一些，方便一些，這也是組件型框架的優勢吧。