由於前段時間使用JSF做了一個項目不少使用JSF的兄弟們對JSF評價並不好因此在學習的過程中一直在想JSF究竟是不是應該繼續學習繼續研究使用下去在看完Seam In Action的第三章後這個星期又對Struts簡單學習了一下終於決定結束JSF和JBoss Seam的學習了
因為從JSF的學習和Struts的學習對比中明顯覺得JSF復雜對於一個技術力量不是非常強的項目組來說使用JSF當你遇到一些問題時絕對是一件痛苦的事情
從自己的實踐中覺得JSF至少有兩個致命傷
覺得JSF貌似把簡單的事情搞得復雜化了在傳統的MVC框架如Struts中從request中獲取param很容易也可以將param封裝為對象在JSF中希望將這一切都模型化一切都以組件為中心類似於Swing的架構但是http的無狀態以及web的本質使得一般JSF只能將組件樹存放在服務端同時又不能象CS程序那樣方便的查看組件的狀態屬性等信息對於通常情況來說JSF將其封裝的很好不用我們開發者操心但是當遇到一些問題時對於開發者想去調試查看問題時問題就顯得很復雜了
JSF的自定義組件感覺超復雜難度應該比當年自定義JSP標簽更要高試想一下如果哪個組件不合意了想改一下還是比較困難的除非對JSF組件有相當的深入了解
順便把項目中遇到的一個RichFaces的缺點列出來
RichFaces在生成組件的html時大量使用了Div曾經有過一個頁面有千多行（在一個table中）頁面上還有一個RichFaces的下拉菜單從而導致菜單響應非常之慢後來只有將richdatatable換為普通的htmltable就沒有問題了
再看看Seam In Action中總結的JSF的缺點
在JSF中初次請求的處理流程太過簡單而後續請求則執行了完整的復雜的處理流程在JSF中假設第一個調用應該是在頁面被渲染後執行但實際中有時我們需要在第一次請求時就執行某些操作在JSF中缺少象Struts中的Controller
所有的請求都是POST浏覽器處理POST請求是比較草率當用戶執行了一個JSF Action操作後點擊浏覽器的刷新按鈕時浏覽器會詢問用戶是否重新提交這會令用戶非常困惑
僅僅擁有簡單基礎的頁面導向機制
過度復雜的生命周期
JBossSeam宣稱對於JSF存在的缺點都提供了解決方法但是有一種更復雜的感覺
在Seam中生成選擇的項目時有EAR和WAR的選項如果選擇了EAR選項那麼Seam會生成四個項目分別為warearejbtest四個類型的項目有一次我將生成的項目從一個目錄拷貝到另一個目錄切換了Eclipse的workspace此時問題來了ejb項目提示編譯錯誤提示無法找到某些class找來找去找來找去……後來將項目關閉了一下再打開錯誤提示就沒有了
由這個問題我忽然想到使用Seam集成JSFEJB是不是太重量級了如果采用EJB作為替代普通的POJO對於一個小型的項目組來說一般的規模就是三至五個人（我個人的理解）開發人員本來就不多還要面對Seam劃分的四個項目好像比較繁瑣當然采用war模式另當別論
相比較而言這個星期看了一些Struts的資料覺得Struts的架構非常清晰易於理解
翻了很早之前的JavaEye上的一個帖子提到JSF是面向開發工具的如果能做到象VB那樣就大有前途了年過去了不要提JSF的開發工具了就是Java各個方面的GUI開發工具又有哪個能和VB相比呢看來選擇JSF作為一個方向不是一個好選擇……還是及早放棄吧哎……
最後我覺得可以用這麼一句話可以形容JSF看起來很美用起來不爽
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28753.html
