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表單提交和有參數的鏈接

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了，這屬于串行方式。