由于前段時(shí)間使用JSF做了一個(gè)項(xiàng)目，不少使用JSF的兄弟們對(duì)JSF評(píng)價(jià)并不好，因此在學(xué)習(xí)的過(guò)程中一直在想，JSF究竟是不是應(yīng)該繼續(xù)學(xué)習(xí)繼續(xù)研究使用下去，在看完Seam In Action的第三章后，這個(gè)星期又對(duì)Struts2簡(jiǎn)單學(xué)習(xí)了一下，終于決定結(jié)束JSF和JBoss Seam的學(xué)習(xí)了。

    因?yàn)閺腏SF的學(xué)習(xí)和Struts2的學(xué)習(xí)對(duì)比中明顯覺(jué)得JSF復(fù)雜，對(duì)于一個(gè)技術(shù)力量不是非常強(qiáng)的項(xiàng)目組來(lái)說(shuō)，使用JSF當(dāng)你遇到一些問(wèn)題時(shí)，絕對(duì)是一件痛苦的事情。

    從自己的實(shí)踐中覺(jué)得JSF至少有兩個(gè)致命傷：

    1、覺(jué)得JSF貌似把簡(jiǎn)單的事情搞得復(fù)雜化了，在傳統(tǒng)的MVC框架如Struts中，從request中獲取param很容易，也可以將param封裝為對(duì)象，在JSF中，希望將這一切都模型化，一切都以組件為中心，類(lèi)似于Swing的架構(gòu)，但是http的無(wú)狀態(tài)以及web的本質(zhì)，使得一般JSF只能將組件樹(shù)存放在服務(wù)端，同時(shí)又不能象CS程序那樣方便的查看組件的狀態(tài)、屬性等信息。對(duì)于通常情況來(lái)說(shuō)，JSF將其封裝的很好，不用我們開(kāi)發(fā)者操心，但是當(dāng)遇到一些問(wèn)題時(shí)，對(duì)于開(kāi)發(fā)者想去調(diào)試查看問(wèn)題時(shí)，問(wèn)題就顯得很復(fù)雜了。

    2、JSF的自定義組件感覺(jué)超復(fù)雜，難度應(yīng)該比當(dāng)年自定義JSP標(biāo)簽更要高，試想一下，如果哪個(gè)組件不合意了，想改一下，還是比較困難的，除非對(duì)JSF組件有相當(dāng)?shù)纳钊肓私狻?/p>

    順便把項(xiàng)目中遇到的一個(gè)RichFaces的缺點(diǎn)列出來(lái)：

    RichFaces在生成組件的html時(shí)，大量使用了Div，曾經(jīng)有過(guò)一個(gè)頁(yè)面有1千多行（在一個(gè)table中），頁(yè)面上還有一個(gè)RichFaces的下拉菜單，從而導(dǎo)致菜單響應(yīng)非常之慢，后來(lái)只有將rich:datatable換為普通的html:table，就沒(méi)有問(wèn)題了。

    再看看Seam In Action中總結(jié)的JSF的缺點(diǎn)：

    1、在JSF中初次請(qǐng)求的處理流程太過(guò)簡(jiǎn)單，而后續(xù)請(qǐng)求則執(zhí)行了完整的復(fù)雜的處理流程。在JSF中假設(shè)第一個(gè)調(diào)用應(yīng)該是在頁(yè)面被渲染后執(zhí)行，但實(shí)際中有時(shí)我們需要在第一次請(qǐng)求時(shí)就執(zhí)行某些操作。在JSF中缺少象Struts中的Controller。

    2、所有的請(qǐng)求都是POST。瀏覽器處理POST請(qǐng)求是比較草率，當(dāng)用戶執(zhí)行了一個(gè)JSF Action操作后，點(diǎn)擊瀏覽器的刷新按鈕時(shí)，瀏覽器會(huì)詢問(wèn)用戶是否重新提交，這會(huì)令用戶非常困惑。

    3、僅僅擁有簡(jiǎn)單基礎(chǔ)的頁(yè)面導(dǎo)向機(jī)制。

    4、過(guò)度復(fù)雜的生命周期。

    JBossSeam宣稱(chēng)對(duì)于JSF存在的缺點(diǎn)都提供了解決方法，但是有一種更復(fù)雜的感覺(jué)。

    在Seam中，生成選擇的項(xiàng)目時(shí)，有EAR和WAR的選項(xiàng)，如果選擇了EAR選項(xiàng)，那么Seam會(huì)生成四個(gè)項(xiàng)目，分別為war、ear、ejb、test四個(gè)類(lèi)型的項(xiàng)目。有一次我將生成的項(xiàng)目從一個(gè)目錄拷貝到另一個(gè)目錄，切換了Eclipse的workspace，此時(shí)問(wèn)題來(lái)了，ejb項(xiàng)目提示編譯錯(cuò)誤，提示無(wú)法找到某些class，找來(lái)找去找來(lái)找去......后來(lái)將項(xiàng)目關(guān)閉了一下，再打開(kāi)錯(cuò)誤提示就沒(méi)有了。

    由這個(gè)問(wèn)題我忽然想到，使用Seam集成JSF、EJB是不是太重量級(jí)了，如果采用EJB作為替代普通的POJO，對(duì)于一個(gè)小型的項(xiàng)目組來(lái)說(shuō)，一般的規(guī)模就是三至五個(gè)人（我個(gè)人的理解），開(kāi)發(fā)人員本來(lái)就不多，還要面對(duì)Seam劃分的四個(gè)項(xiàng)目，好像比較繁瑣，當(dāng)然采用war模式另當(dāng)別論。

    相比較而言，這個(gè)星期看了一些Struts2的資料，覺(jué)得Struts2的架構(gòu)非常清晰，易于理解。

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

    最后我覺(jué)得可以用這么一句話可以形容JSF，看起來(lái)很美，用起來(lái)不爽。