Tapestry和JSF的比較

這篇文章主要介紹“Tapestry和JSF的比較”，在日常操作中，相信很多人在Tapestry和JSF的比較問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Tapestry和JSF的比較”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1．JSF和Tapestry性能方面

JSF

從測試數據可以看出在只使用JSF及JSF自定義組件的情況下,webmail demo應用速度最快，200用戶并發訪問的響應時間為1.8秒，基本上可以達到servlet + jsp的性能。

使用JSF + 5個Facelet composition組件的情況下，webmail demo應用仍可達到200用戶并發訪問的響應時間為2.6秒的性能。

使用JSF + 20個Facelet composition組件的情況下,webmail demo應用可達到200用戶并發訪問的響應時間為3.1秒的性能。

如果在業務層方法沒有大的效率問題、并在壓力較大的頁面適當使用緩存的情況下，JSF應用程序可以達到在dell 2850機器上100-200并發5秒內響應的性能

Tapestry

從測試數據可以看到tapestry在使用相同數量框架自身提供組件的情況下，運行效率比JSF明顯要低一些，但也算是在可以接受的范圍內。

2．JSF和Tapestry開發方面

JSF

JSF對servlet API進行了封裝，程序員在使用組件做JSF應用程序的開發時基本上不需要直接操作HttpRequest和HttpResponse,并且對用戶輸入驗證，手機等其它設備（通過rendererKit），多語言(通過資源文件方式)和換膚（通過rendererKit）的支持都有相應的封裝，可以方便的實現。目前開源的組件庫有MyFaces,ADF等可以使用,其中有些組件內置AJAX支持。

開發工具中IBM WebSphere Studio,Oracle JDeveloper 10g和FaceIDE等IDE對JSF應用開發提供可視化編輯支持。下面是對JSF自定義組件和JSF+facelet composition組件開發進行比較

JSF自定義組件開發:

JSF自定義組件由java代碼和tag庫文件組成，開發難度應該與現有I2SS組件開發的難度基本一致,JSF自定義組件通過自定義標記構造頁面，在頁面上增加組件的數量對性能有較大的影響。

JSF + facelet composition組件開發:

facelet composition組件在個性化、重用方面對JSF提供了很好的補充。通過編寫tag庫文件，使用facelet可以把多個JSF自定義組件組合成facelet composition組件，或者把幾個facelet composition組件組合成新的facelet composition組件,這個過程不需要開發或設計人員編寫Java代碼。facelet composition組件是live模式運行時生成，從測試結果上看組件數量對性能的影響不大

學習曲線上,開發難度與組件基本一致,只要寫過組件或寫過servlet+jsp的人,加上適當培訓,一周內都可掌握JSF或Tapestry開發

Tapestry

組件和頁面的開發過程完全一致，都是由模板、page/component class和specification文件組成。IDE方面目前有開源社區開發的eclipse插件Spindle和Tapestry Palette可用，對開發效率有一定的提升。

3.JSF和Tapestry集群支持方面

JSF

目前在I2SS上做的集群實驗是使用apache+jboss來實現，結構是apache做集群前端實現stick session，jboss做應用服務器。

I2SS架構應用程序Session中放入的對象并不能全部串行化，所以在做集群時只能使用粘貼會話方式(stick session)實現,這樣容易出現的情況是如果一臺機器down掉，這臺機器上的所有在線用戶都會無法繼續當前的會話。如果用戶重新發起登錄請求，任務會轉移到其它正常工作的機器上。如果down掉的機器重新恢復，轉移到其它機器上的用戶不能重新使用這臺新啟動的機器，只有新發起的用戶請求和在線用戶調用session.invalidate()顯式退出后，工作才會轉移到新啟動的機器上，這樣負載的均衡時間會比較長。I2SS架構應用程序可以通過更改框架層，將現有放入session中的對象實現串行化，并且將不能串行化的對象放到session以外的地方來實現使用session replication的集群模式。

在JSF上做的集群實驗是使用apache+jboss來實現,支持stick session和session replication兩種模式。stick session模式的結構和討論如上述，session replication的結構是apache做集群前端,通過jboss的TreeCache實現session replication。在編寫JSF程序時要把放入會話中的backing-beans實現串行化，如果一臺機器down掉，在線用戶的會話會轉移到其它正常工作的機器上，對于用戶的感受來說可能是速度變慢，但是不會出現會話斷掉的情況。如果down掉的機器重新恢復，TreeCache通過網卡或文件系統完成session replication的過程后，在線用戶的任務就可以實現與機器未down時相同的負載均衡狀態。如果想減少網卡或文件系統的I/O操作，可以通過集群分區來實現。

Tapestry

Tapestry本身提供兩種state持久方式：傳統的session方式和client-side方式。狀態保存在session中的情況下，實現集群和JSF方式一樣，需要session replication。保存在client-side的情況下，有一些局限性，但是可以實現無狀態的應用，自動支持集群。

4.對于I2SS組件與JSF組件混合使用的說明

JSF組件應用程序是標準J2EE應用程序，JSF組件對servlet API提供了封裝，同時也提供了直接得到servlet上下文的方法，所以I2SS組件與JSF組件的混合使用與現在已經實現的郵件系統中servlet+JSP與I2SS組件的混合使用方法是一樣的，都可以用手動創建EbiContext實例的方法來實現。

5.目前JSF標準的進展情況，以及行業的支持情況

JSF 體系結構
JavaServer Faces 的 MVC 實現
JSF 的主要優勢之一就是它既是 Java Web 用戶界面標準又是嚴格遵循模型-視圖－控制器 (MVC) 設計模式的框架。用戶界面代碼（視圖）與應用程序數據和邏輯（模型）的清晰分離使 JSF 應用程序更易于管理。為了準備提供頁面對應用程序數據訪問的 JSF 上下文和防止對頁面未授權或不正確的訪問，所有與應用程序的用戶交互均由一個前端“Faces”servlet（控制器）來處理。

到此，關于“Tapestry和JSF的比較”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！