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