由于前段時間使用JSF做了一個項目，不少使用JSF的兄弟們對JSF評價并不好，因此在學習的過程中一直在想，JSF究竟是不是應該繼續學習繼續研究使用下去，在看完Seam In Action的第三章后，這個星期又對Struts2簡單學習了一下，終于決定結束JSF和JBoss Seam的學習了。

    因為從JSF的學習和Struts2的學習對比中明顯覺得JSF復雜，對于一個技術力量不是非常強的項目組來說，使用JSF當你遇到一些問題時，絕對是一件痛苦的事情。

    從自己的實踐中覺得JSF至少有兩個致命傷：

    1、覺得JSF貌似把簡單的事情搞得復雜化了，在傳統的MVC框架如Struts中，從request中獲取param很容易，也可以將param封裝為對象，在JSF中，希望將這一切都模型化，一切都以組件為中心，類似于Swing的架構，但是http的無狀態以及web的本質，使得一般JSF只能將組件樹存放在服務端，同時又不能象CS程序那樣方便的查看組件的狀態、屬性等信息。對于通常情況來說，JSF將其封裝的很好，不用我們開發者操心，但是當遇到一些問題時，對于開發者想去調試查看問題時，問題就顯得很復雜了。

    2、JSF的自定義組件感覺超復雜，難度應該比當年自定義JSP標簽更要高，試想一下，如果哪個組件不合意了，想改一下，還是比較困難的，除非對JSF組件有相當的深入了解。

    順便把項目中遇到的一個RichFaces的缺點列出來：

    RichFaces在生成組件的html時，大量使用了Div，曾經有過一個頁面有1千多行（在一個table中），頁面上還有一個RichFaces的下拉菜單，從而導致菜單響應非常之慢，后來只有將rich:datatable換為普通的html:table，就沒有問題了。

    再看看Seam In Action中總結的JSF的缺點：

    1、在JSF中初次請求的處理流程太過簡單，而后續請求則執行了完整的復雜的處理流程。在JSF中假設第一個調用應該是在頁面被渲染后執行，但實際中有時我們需要在第一次請求時就執行某些操作。在JSF中缺少象Struts中的Controller。

    2、所有的請求都是POST。瀏覽器處理POST請求是比較草率，當用戶執行了一個JSF Action操作后，點擊瀏覽器的刷新按鈕時，瀏覽器會詢問用戶是否重新提交，這會令用戶非常困惑。

    3、僅僅擁有簡單基礎的頁面導向機制。

    4、過度復雜的生命周期。

    JBossSeam宣稱對于JSF存在的缺點都提供了解決方法，但是有一種更復雜的感覺。

    在Seam中，生成選擇的項目時，有EAR和WAR的選項，如果選擇了EAR選項，那么Seam會生成四個項目，分別為war、ear、ejb、test四個類型的項目。有一次我將生成的項目從一個目錄拷貝到另一個目錄，切換了Eclipse的workspace，此時問題來了，ejb項目提示編譯錯誤，提示無法找到某些class，找來找去找來找去......后來將項目關閉了一下，再打開錯誤提示就沒有了。

    由這個問題我忽然想到，使用Seam集成JSF、EJB是不是太重量級了，如果采用EJB作為替代普通的POJO，對于一個小型的項目組來說，一般的規模就是三至五個人（我個人的理解），開發人員本來就不多，還要面對Seam劃分的四個項目，好像比較繁瑣，當然采用war模式另當別論。

    相比較而言，這個星期看了一些Struts2的資料，覺得Struts2的架構非常清晰，易于理解。

    翻了很早之前的JavaEye上的一個帖子，提到JSF是面向開發工具的，如果能做到象VB那樣，就大有前途了，4年過去了，不要提JSF的開發工具了，就是Java各個方面的GUI開發工具，又有哪個能和VB相比呢，看來選擇JSF作為一個方向不是一個好選擇........還是及早放棄吧，哎...

    最后我覺得可以用這么一句話可以形容JSF，看起來很美，用起來不爽。