收藏一篇DLEE老大的文章，里面的話句句說到了我的心坎里。
為什么我說Struts/WebWork會受到Ajax的威脅呢？有的人可能覺得大家相安無事不是很好，你是不是有神經病故意挑起人民內部矛盾？問題是他們之間確實存在著一些深層的內在矛盾和沖突，這些矛盾才是目前Struts和 WebWork都只能在非常有限的程度上支持Ajax的原因。所以，問題是架構性的，并不是小型的修補或者更好的編程技巧可以徹底解決的。
傳統(tǒng)的服務器端MVC架構設計（也就是Model2），存在著一個基本的假設就是Web應用的工作流是由一系列的頁面切換構成的。這種架構中的一個View，從語義上來講只能代表一個完整的HTML頁面。整個Web應用的表現(xiàn)層，被劃分成為非常多的頁面的組合。
而Ajax開發(fā)者眼里，Web應用的工作流并不是這樣構成的。Ajax開發(fā)者看待Web應用的角度與傳統(tǒng)開發(fā)者相比差別非常大。在一個Ajax應用中，只有相對很少的頁面。每個頁面，包括頁面引用CSS樣式、JS腳本，都是一個更小型的Ajax應用。甚至一些功能簡單的Ajax應用，本身僅僅由一個單一的頁面構成。例如一個簡單的RSS閱讀器，還有IBM筆記本上那個獲得天氣預報的桌面。
按照Ajax in Action，Ajax應用可以分成3種類型：
-
以內容為中心的應用，服務器返回的是一段HTML內容。
-
以腳本為中心的應用，服務器返回的是一段JS腳本。
-
以數(shù)據(jù)為中心的應用，服務器返回的是一段數(shù)據(jù)，可以是XML格式、JSON格式或者其他文本格式。
服務器返回給Ajax應用的3種類型的網絡流量（不稱為數(shù)據(jù)是與上面第3種Ajax應用相區(qū)別），任何一種都不能被簡單地視作傳統(tǒng)MVC架構中的View，因為他們各自所代表的語義與傳統(tǒng)MVC架構中的View的語義是完全不同的。所以可以看出，除了初次交付給瀏覽器一個完整的Ajax應用之外，傳統(tǒng)的MVC架構對于Ajax應用的支持是非常有限的。其實為了給客戶端提供上面3類網絡流量，一個Servlet已經足夠了。DWR、JSON-RPC、Buffalo在服務器端也就是由Servlet實現(xiàn)的，不要求服務器端一定要安裝某種MVC框架。
上面3類應用，前面的兩類，客戶端JS代碼比較簡單，表現(xiàn)邏輯僅有一部分位于客戶端，大部分仍然位于服務器端，因此傳統(tǒng)的服務器端MVC架構仍然是非常有價值的。但是大家注意第3類Ajax應用，實際上它已經將絕大部分甚至可以將全部的表現(xiàn)邏輯都轉移到客戶端來執(zhí)行，這個時候服務器端傳統(tǒng)的Web表現(xiàn)層實際上被架空了（皮之不存，毛將焉附？）。而對于Ajax應用來說，雖然近期可能還是以第1類Ajax應用為主（例如，所謂的AHAH技術），但是最有生命力和發(fā)展前景的還是第3類Ajax應用。
自從1999年M$推出IE5.0支持XMLHTTP，可以不刷新頁面以異步方式從服務器獲取數(shù)據(jù)之后，Web開發(fā)的領域就埋下了一顆定時炸彈（6年以后，一個新詞Ajax的出現(xiàn)引爆了這顆炸彈）。Model2最初的設計應該發(fā)生在這件大事（現(xiàn)在應該承認，M$做了一件天大的好事）發(fā)生之前，其設計師不可能想到異步請求的價值。按照Model2的設計思想直接產生了Struts。但是后來的WebWork在最初設計階段仍然與這個技術失之交臂，這是相當可惜的一件事情。WebWork其實最初設計的時候就可以走的更遠，但是他們只想超越Struts，做一個更好的Model2 MVC開發(fā)框架。現(xiàn)在他們再想趕上這班列車已經有點晚了。如果基礎的服務器端MVC架構的價值是可疑的，那么其他圍繞這個架構所開發(fā)的基礎架構的價值也同樣是可疑的。
所以在現(xiàn)在這個時刻，重新正本清源地思考Model2最初的設計，它帶來的Web開發(fā)的巨大進步，以及它所存在的不足，是一個非常現(xiàn)實的問題。