細說框架風雲,JSF能否拯救WEB江湖
Java企業開發可以說是“復雜”的代名詞,簡化Java的開發已經刻不容緩了.隨著JAVA EE 5，JAVA EE6的相繼發布，從老虎到野馬，版本更新如此之快，對SUN來說是史無前例的。Sun終於頂不住來自內部改革派和外部竟爭者的壓力。看來是下定決心簡化 Java了！
在2005年底.Net 2.0的發布，我們目睹了.Net 2.0的成功。.Net 2.0由於開發簡單，開發周期短，開發成本低，中小企業紛紛轉投向.Net的懷抱。眼看Java EE的市場慢慢的被.Net蠶食，Sun是急在眼裡，痛在心裡。
JSF也隨之成為JAVA EE的規范，Java EE 6明顯加強對JAVA開發桌面應用的支持，Sun也想讓Java在桌面開發中占有一席之地。而把JSF作為強制規范，是想通過JSF來繼續統領WEB 開發來固守企業應用的市場，2007年，Sun想通過JSF來打一個翻身仗。
WEB江湖
自Java 1995年面世後，Sun靠Applet 搶占了WEB前端市場，而Flash的出現卻讓Applet早早退出歷史舞台。於是Sun在1997年發布了第一個WEB服務器（Java WEB Server）及應用的Servlet API。Servlet可以通過純Java語言來編寫企業WEB應用，Servlet從廠商急需角度出發，迅速的成為了企業應用解決方案的標准。
雖然Servlet通過Java這種高級語言來進行編寫，而最終是展示給用戶的。需要有良好的用戶界面。這就需要支持HTML等WEB腳本。可是Servlet卻不能良好的嵌入Html等前端代碼，開發起來非常復雜。
終於在1998年，Sun推出了JSP。而此時，與之相似的ASP已經發布了兩年之久。Sun在1999年初推出JSP 1.0後，又在1999年11月推出JSP 1.1，Sun終於憑借Servlet和JSP技術，迅速的占領了絕大部份的企業市場份額。在2002年4月，JSP發展到1.2版本。到2003年 Sun推出JSP 2.0，同時推出的JSTL(JAVA 標准標記語言)取代JSP表達式的弱點，更進一步簡化JSP的編寫。 JSP慢慢變成一種非常成熟的WEB技術，JSP憑借其技術成熟，穩定，及Java的強大功能和跨平台能力成為WEB企業應用的王者，占領了80%以上的企業應用市場。而ASP則靠快速開發，方便發布以及依靠在微軟的大樹下分食中小市場和個人用戶。
江湖混戰,框架興起
JSP是一項成功的技術，它功能強大，具有高穩定性和可靠性。但是也就意味著他具有復雜性，難以維護。從它誕生起，人們就一直在努力尋找一種快速的web開發方案。
在早期，所有的業務方法，數據庫連接，訪問方法的這些代碼都充斥在JSP頁面裡。開發人員既是UI設計者又是程序員。同時各種各樣的業務代碼寫進JSP頁面中，相同的功能代碼可能需要編寫多次，代碼無法重用，如果後期因為業務的變動而進行維護時，對開發人員簡直就是一場惡夢。
隨後web開發進入Model 2時代，也就是MVC模式的應用時代，MVC模式可以使模型，視圖，控制分離出來。通過Servlet與JSP的結合,由控制器Servlet控制請求，調用業務類獲得模型數據，並把數據模型展示到相應的視圖(JSP)中。這樣，業務方法已經從JSP中分離出來，減少了邏輯代碼與JSP代碼的藕合。JSP 僅僅用於顯示數據和提交用戶的請求。Servlet控制用戶的請求及調用Java類的業務方法,並對用戶的請求進行轉發。MVC模式可使得業務方法重用，使得頁面開發人員和程序員進行分工。一部分人專注於頁面的開發，而一部份人進行業務代碼的編寫。可以使項目組的人去做他最熟悉的工作。
Model2的運用，對web開發帶來了一次全新的變革，但是仍然面臨著許多問題。有太多的Servlet類，一個請求對應著一個Servlet類。頁面流程的控制全部通過硬代碼寫死在Servlet類中，每一個Servlet類都需要在WEB.XML中進行配置，不能很好的支持國際化等。後來人們通過前端控制器模式來解決了這樣問題，就是由一個Servlet來響應所有的請求。根據不同的請求參數來調用不同的服務方法。這樣有效的減少了Servlet 類。幾乎現在所有的WEB框架都是采用前端控制器和MVC模式的運用。在這樣的背景下，WEB框架應運而生，Struts最先面世，WEBWork等紛紛湧現。開發者采用框架大大的簡化了WEB應用的開發，加快了開發的速度和質量。
Struts攪亂WEB格局
Struts采用前端控制器模式和MVC模式進行設計。強制開發人員以MVC的理念來進行web開發，把表現層與業務層進行分離。Struts提供了豐富的標簽庫，在JSP 1.1時代，JSP頁面都是通過JSP表達式進行編寫。雖然采用“<%%>”的JSP表達式功能非常強大，但是調試十分的麻煩，理解也十分的困難，一般的頁面人員幾乎無法勝任。而Struts此時提供的標簽庫類似於Html的標記，對開發人員更為友好,易於理解和編寫。
Struts提供了一個頁面流程控制的功能，而不是把頁面的轉向寫死在代碼中。每個請求的頁面輸入和頁面轉發都配置在Struts-config.XML中。
Struts支持自動數據綁定，通過一個ActionForm來實現。把頁面的數據自動綁定成POJO對象。並支持數據檢驗。Struts 提供了國際化的支持，可以很容易的讓你的WEB系統應用於多種語言版本的要求。
所以Struts一推出就受到了開發人員的喜愛，並迅速流行起來。Struts是目前使用最多,流行時間最長的Java開源 WEB框架。
盡管Struts取得了成功，但是它仍然有很多的不足。Struts線程是安全的，但對並發控制是一個問題。在JSP 2.0推出JSTL後。JSTL取代JSP表達式進行JSP編寫，JSTL是一種類似C語言風格的標記語言。更為人們所熟悉，語法十分簡單，明了,功能強大。JSTL會自動處理NULL問題，而不是像JSP表達式和Struts標簽那樣遇到NULL值是會拋出可恨的異常。相對於優雅的JSTL，采用 Struts標簽寫出的JSP代碼就像是天書，咒語一樣。Struts大部份標記重復了JSTL的相似功能，有一部份與Html重復的標簽根本就沒有必要存在，還無端的增加了學習和開發的難度。而且Struts標簽不能良好的處理NULL問題。
ActionForm的問題，Struts通過ActionForm來進行數據綁定和數據校驗。首先任何需要使用數據綁定和數據校驗功能都必須去繼承 ActionForm，而Action Form又依賴Servlet。這樣基於類繼承的藕合是沒有必要的。數據綁定應該是原始的，就是說頁面的數值型數據應該綁定成Java類的數值型數據，日期型數據就綁定成日期數據。而Struts只能把頁面數據綁定成字符型的數據。數據校驗應該是具有重用性的，而Struts卻要把數據檢驗生硬的寫在 ActionForm中。
同時Struts也存在以下幾點致命傷：
1、Struts通過繼承具體類來進行擴展，那麼你要自定義Struts的行為而變得困難。
2、Struts是不容易測試的，必須通過StrutsTestCase來進行輔助測試。而不是真正意義上的單元測試。
3、Struts太面向JSP了，也就是說Struts僅支持JSP，如果我們的應用有些視圖不是采用JSP，而另外一些視圖如采用Excel和PDF。那麼Struts是無能為力的。
4、Struts框架對異常沒有提供一個良好的支持。
Struts也看到了自身存在的缺陷，並不斷進行改進，隨著Struts 2的到來，會帶來一些改變的。
WEBwork是一種比Struts更易於使用，基於Command模式的開源WEB框架。WEBwork結構十分的簡單，也提供了豐富的標簽庫，WEBwork的攔截器也十分的優秀。並且WEBwork是非線程的。WEBwork提供了一個IOC容器，支持國際化，並且支持多種視圖技術。可以說WEBwork是一個非常優秀的WEB框架。但是WEBwork的開發文檔少得可憐,它的客戶端驗證技術不太成熟，Velocity Templates技術還是太復雜，不提供對組件的封裝,而Struts的Tiles更好一點。采用WEBwork，必須對它的運行機制十分了解。同時 WEBwork對每個用戶交互都強加Command模式，而不管是否需要。所有Command 的excute方法被迫拋出Exception，你無法知道哪一命令會拋出什麼類型的異常，而且WebWork的路注定是沒有歸途的。
Spring Web框架中一條黑馬
2001年Rod Johnson編寫一本書叫《J2EE設計開發編程指南》。這本書的內容構成了Spring框架的雛形。接著Rod Johnson又編寫了另外一本書《J2EE without EJB》,並同時推出Spring框架。這兩本書迅速的在業界引起了轟動，為Spring的推出作了很好的鋪墊。Spring引入IOC（控制反轉）的概念，采用POJO對象，AOP支持和輕量級容器來開發企業應用，這些正是業界多年來一直苦苦尋找的解決方案。Spring一推出就紅遍了大江南北，迎來了 Java企業開發的春天。
筆者認為Spring MVC 是基於請求響應模式最為優秀的開源WEB框架。它來自於Spring，天生就支持IOC 和AOP，這是其它任何WEB框架無法相比的。
◆Spring MVC 是一個很薄的WEB框架，它清晰的分離了數據和視圖。支持多種視圖技術(JSP,XML,Excel, PDF…)十分方便。
◆Spring的優勢
◆Spring MVC對於表單提交類的應用提供了一個完整的生命周期。
◆Spring MVC支持頁面數據的原生綁定為POJO對象，並可以自定義擴展綁定器，而不是像Struts那樣只能把頁面數據自動綁定為String 類型。
◆Spring MVC 自定義行為變得十分容易，這得益於Spring框架良好的設計，Spring MVC的控制器也是基於Command模式的。
◆Spring MVC 有良好的數據校驗框架，也很容易自定義數據校驗行為。
◆Spring MVC 提供了一個良好的異常處理機制，可以方便的自定義各類異常的處理行為。
◆Spring MVC 提供了有用的標簽。（注意是有用的，沒有用的Spring絕不提供）
◆Spring MVC 支持I18N及文件上傳等。
◆Spring 還推出了Spring WEB Flow,用於向導式的WEB應用開發。
Rod Johnson 是一個Java EE專家，我更願意稱他為一個實踐家。Rod Johnson 的經典語錄是“不要重復發明輪子”，Spring 框架的各方面應用都來源於長期的實踐經驗，集百家之長，吸收其它框架的精華,正是Spring取得成功的原因。Spring MVC也是如此。Spring提供給你真實需要的，通過長期實踐證明的東西。
雖然Spring 已經大紅大紫了，但是Spring MVC卻沒有流行起來。它出來太晚了，而Struts已經深入人心了，Struts這麼多年的表現一直不錯，雖然Struts並不是那麼優秀。但是它有著龐大的開發人群，關於Struts的資料是鋪天蓋地。企業很容易找到Struts開發人員,卻難以找到Spring MVC開發人員。另外一個客觀原因就是Spring太靈活了，Spring MVC也不例外，正因為Spring MVC過於靈活，致使初學者望而生畏。Spring MVC需要進行過多的XML配置,Spring MVC的文檔相對比較少，所以現在Spring MVC的使用者有限，但無論如何，Spring MVC是一個非常優雅的web開發框架，花費一點學習成本是值得的。
ASP.Net的成功說明了什麼？
ASP.Net是一種面向組件，基於事件驅動模型的WEB開發技術。在基於請求驅動模型的WEB開發技術中(如JSP和ASP)，程序代碼需要混合在 Html標簽中。而事件驅動模型與請求驅動模型相比，在一個表單上的組件通過激活應用程序的事件來響應用戶的行動。開發人員通過為組件的相關事件編寫相應的程序代碼來實現相關的邏輯。事件驅動模型的WEB開發技術提供了一種更為直觀的編程模式，使得web開發就像編寫一個VB或Java Swing桌面應用程序一樣。用鼠標把相應的控件拖到頁面視圖，然後再為控件編寫相應的事件代碼來實現業務邏輯。這樣，就把WEB前端開發變成了運用高級語言進行程序開發(在ASP.NET中采用VB..Net或C#)。面向組件和基於事件驅動模型使得web開發真正的回歸到了傳統的開發方式。大大的簡化了WEB項目開發的復雜度。
ASP.NET提供了豐富有WEB前端組件。因為ASP.Net是面向組件的，和基於事件的。所以ASP.Net必須提供豐富的組件，並為這些組件定義相關的事件。讓開發人員去擴展事件代碼來完成邏輯功能。ASP.NET 一開始就提供最實用的WEB組件，如DataGrid用於數據顯示，開發人員只需要通過設置屬性就可以實現自定義分頁顯示。而在以前的ASP或JSP則需要編寫大量的程序代碼才能完成。到ASP.NET 2.0時，微軟更是提供了近150多個WEB組件，如在web開發中經常用到的樹形菜單組件，下拉菜單組件，文件上傳組件等。ASP.Net通過提供這些豐富而功能強大的組件，使得WEB應用開發就像桌面應開發一樣簡單。
正因為ASP.Net帶來了一種全新的開發模式，使得以往復雜的WEB應用開發變得簡單，讓WEB應用更易於發布，並通過微軟的商業運作，ASP.Net一掃ASP的陰霏，迅速的占據了大量企業市場份額。
ASP.Net的成功對我們有什麼啟示呢？可以肯定面向組件、基於事件驅動模型是未來web開發技術的發展方向。ASP,JSP等基於請求驅動式的WEB技術必將退出歷史的舞台。
因為由廠商來提供豐富而實用的組件，大大簡化WEB前端的開發量和開發難度。把復雜的問題交由廠商或開源組織去解決。基於事件驅動模型才是真正的把UI人員和業務程序員分離開來。只有把程序代碼與Html標記分離，才能真正做到UI設計者與程序員分離。
面向組件，基於事件驅動的WEB框架要取得成功必須提供大量實用的WEB組件。只有提供了豐富的，功能強大的WEB組件，開發人員才能從web開發中解脫出來。否則如果每個用戶都需要去實現自己的組件庫，那樣的工作量也是非常龐大的。特別是針對一些小型用戶。必須要有優秀的IDE工具配套支持，如果沒有 VS 2003或VS2005開發工具，而是通過簡單的文本編輯工具來進行ASP.Net開發，很難想像ASP.Net會成功。要真正的實現像VB或Java Swing編寫桌面應用程序那樣來開發WEB應用程序，優秀的IDE工具是必不可少的。允許你把組件從組件面板拖放到頁面上並通過屬性編輯器來定義它的外觀和行為，直接為組件的相關事件編寫事件代碼。
JSF及它的未來
Java Server Faces 簡稱JSF,是一種面向組件和事件驅動模型的web開發技術。JSF的誕生還要追溯到2001年。在2001年5月,Sun制定了一個用戶界面框架的規范JSR#127.
而JSF 規范的1.0到2004年3月才得以面世。直到JAVA EE 5的發布，JSF推出1.2版本並作為JAVA EE 5的一部分同時發布。歷經5年的風雨，JSF現在成為了Java企業應用規范的一部份。
我在上節討論ASP.NET的成功時，已經介紹了面向組件，基於事件驅動模型的web開發技術的優勢。並從ASP.Net的成功可以看出面向組件和基於事件驅動模型是未來WEB技術的發展方向。
從技術上來看JSF是非常先進的，提供了很多復雜的組件支持類似Spring的依賴注入功能。頁面流程控制也通過Faces-config.XML來配置，而不是寫死在代碼裡。這有點與Struts類似。同時像SUN，Oracle,Boland,IBM等公司都為JSF提供了開發環境，Sun的 Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g都是免費的JSF開發工具,像Eclipse也有相應的插件提供對JSF的支持。JSF技術也同時得到了許多廠商的支持，如Sun的JSF WEB UI,IBM的JSF extension,Oracle的ADF Faces.還有許多開源項目如My Faces都提供了對JSF的支持和擴展。
這樣看來，JSF成為了Java EE的標准，又得到了眾多廠商和組織的支持，那麼JSF應該是前途一片光明啦?
何以見得，JSF錯過了它的最好發展時期。Sun其實很早之前就想簡化JSP的開發，用一種新的技術來取代JSP。從而簡化整個WEB層的開發。於是在 2001年就開始制定了JSF的規范，但是由於SUN的官僚作風及商業推廣的失敗，JSF一直未能走向前台。如果SUN能在2002年或2003年，在 JSP最紅火的時候全力推出JSF。取名為JSP 2.0或JSP 3.0。而不是一意孤行的取名為JSF，那麼現在Java的web開發早已經是面向組件和基於事件驅動了。
成熟和穩定方面：
JSP的確是一種非常成熟和穩定的技術，就是因為JSP太成熟了，所以才導致了JSF的發展緩慢。世界上有太多采用JSP技術的成功案例，SUN非要把 JSF變成一個新生兒，誰也不願意去冒這個風險。雖然采用JSP技術進行web開發是復雜的，而且開發周期要長，但是它是穩定並且成熟的WEB技術。 JSP已經占據了大量的市場份額，如果JSF要想取代JSP，那麼JSF就必須有成功的案例來證明JSF能像JSP那樣可靠和穩定。
廠商的支持方面：
廠商對JSF的支持遠遠不夠。從JSF1.0，到JSF1.2的發布並成為JAVA EE的標准，經歷了近五年的時間。各個廠商一直對JSF持觀望的態度，其實主要還是取決於SUN。如果SUN在早期就把JSF作為Java EE的標准，那麼現在JSF已經是遍地開花了。JSF的命運從一開始就像EJB，在實驗室時呆了5年之久，要把它定制成一個大而全的規范是不可能的，任何技術都應該聽取開發人員的意見，EJB的失敗已經充分的證明了在辦公室寫出的規范並不是開發人員所需要的。
雖然IBM，Oracle等廠商現在都已經提供了對JSF的支持，但是他們提供的JSF組件庫都非常有限，而且有些組件是已經過時的組件。同 ASP.NET 2.0相比，各廠商對JSF的支持遠遠不夠，這又怎麼能夠吸引開發者和企業選擇JSF呢？同時，ASP.Net 2.0定義的頁面的生命周期要比JSF靈活及有用得多。而JSF的生命周期則顯得生硬和呆板。
我們上節說到ASP.Net的成功離不開VS 2003和VS 2005這些優秀的IDE開發工具的支持。雖然有Sun的Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g免費支持JSF開發，但它們都不是最主流的JAVA 企業應用開發工具。而像目前最主流的ECLIPSE卻沒有很好的支持JSF的開源免費插件。在開源的大旗下，恐怕很少有人會再去選擇收費的開發工具吧。 web開發只是JAVA企業應用開發的一部份，而不是全部。希望哪一天能見到Sun或IBM這樣的商業公司來為ECLIPSE這些主流IDE開發支持 JSF的插件。其實世面上還有一些專門針對JSF的開發工具，但是我們要知道，JSF僅僅是Java企業應用開發的一部份，我們更需要一個成熟的集成開發環境，如重構，單元測試，甚至整個項目的生命周期管理。我們需要的是在一個主流的成熟的集成開發環境上提供對JSF的支持，而不是那些的專門針對JSF的單一編輯工具。
Sun商業策略方面：
SUN的商業推廣策略也是JSF能否成功的關鍵。SUN不缺技術，但是缺商業推廣。JSF遲遲未能成為Java EE的標准，延誤了JSF的推廣。把JSF取名為JSP 3.0都可能對JSF發展更為有利。很多時機被SUN一再錯過了，才讓JSF在今天顯得如此的尴尬。JSF社區的建設及該如何吸引開發人員和企業轉向 JSF？SUN的商業推廣策略是至關重要的。
天將降大任於斯JSF也！！！雖然web開發技術注定要進入面向組件和基於事件驅動的時代， JSF 能否拯救WEB的江湖呢？讓我們共同拭目以待吧！！
