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

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

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

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

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

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

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

組件必須繼續(xù)ActionForm

　　Struts組件編程模型

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

　　一般分兩種情況：假如同一個(gè)Action就可以對(duì)付這些組件，那么在這種情況下有兩個(gè)辦法：

　　1.將這多個(gè)組件裝入一個(gè)ActionForm中，如使用MapForm等機(jī)制；

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

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

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

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

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

　　Struts組件模型缺點(diǎn)

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