用過一段時間的Woodstock,當時感覺有點爽，但后來對于組件的控制方面的不是很好，沒有在畢業設計上使用. 對于JSF想到了一些缺點，在這里分析一下。只是淺薄見解

1.有狀態編程模型

JSF把Web編程搞的非常像JAVA SE GUI編程模型。維護組件樹、組件狀態。這讓我感覺非常不舒服。Web開發就是Web開發，本身就是無狀態的。所有行為都是基于 request,session,application等范圍。JSF硬要往GUI模型上套，結果就是非常不自然，有點四不像了。而且JSF維持的僅僅是視圖狀態，而不是數據狀態，這種編程模型有點混亂。我認為Web就是Web!

2。面向組件開發，更加OO

這是在討論去里看到有人這樣為JSF宣傳。我承認這句話的陳述是正確的。因為JSF把Web編程基本上變成了JAVA SE的GUI編程。確實是面向組件的。但是通過使用，我覺得這種做法的優勢是否真的有那么大，值得考慮。相比JSF,PHP、Rails、 JSP(JSTL)都沒有刻意提供所謂的組件。這種做法方便了操縱HTML控件，直接、簡單。而使用JSF控件時，則對于他的控制能力變得比較模糊并且不夠靈活。我們需要在Backingbean里對組件進行控制。我感覺--太作做了。而且這種面向組件的方式所代來的好處遠不能抵消它所代來的麻煩。

至于所謂的OO論，表示層的東西有必要刻意強調像JSF這種面向組件，OO嗎？對于Widget那種ajax的HTML面向組件我是可以理解的。 PHP／RoR沒有面向組件但也非常好用。表示層只需要提供一些頁面的重用和插入功能就足以了。這讓我想起了人們對JAVA EE過度分層的抱怨。于Rails形成了鮮明的對比。所謂的OO在服務器端、業務處理的代碼中有很大用處。但是Web是瘦客戶端(不像Swing)！在 Web的表示層中如此大張旗鼓的宣揚JSF式的OO我認為是一種誤區。我們可以看看PHP\Rails這些語言框架，做到MVC，足夠了。Web的表示層需要的最重要的特性就是容易使用、容易控制、容易重用(也面片段)。

JSF那種把HTML和后端弄到一起，模仿Swing,搞OO的做法有點費力不討好的感覺。

【編輯推薦】

1. JSF和Tapestry全面比較
2. 開發自定義JSF組件
3. 簡述學習JSF小記
4. JSF圖形組件管理圖形bean組件
5. Seam與JSF的加減法