通常更多的我們對比?SpringMVC與Struts
把這張圖放在這裏，我是想說SpringMVC和Struts2真的是不壹樣的，雖然在都有著核心分發器等相同的功能組件（這些由MVC模式本身決定的）。
為什麽SpringMVC會贏得最後的勝利呢？談幾點我自己的看法：
第壹、MVC框架的出現是為了將URL從HTTP的世界中映射到JAVA世界中，這是MVC框架的核心功能。而在URL這壹點SpringMVC無疑更加優雅。
第二、從設計實現角度來說，我覺得SpringMVC更加清晰。即使我們去對比Struts2的原理圖和SpringMVC的類圖，它依然很讓人困惑，遠沒有SpringMVC更加直觀：
SpringMVC設計思路：將整個處理流程規範化，並把每壹個處理步驟分派到不同的組件中進行處理。
這個方案實際上涉及到兩個方面：
l?處理流程規範化?——?將處理流程劃分為若幹個步驟（任務），並使用壹條明確的邏輯主線將所有的步驟串聯起來
l?處理流程組件化?——?將處理流程中的每壹個步驟（任務）都定義為接口，並為每個接口賦予不同的實現模式
處理流程規範化是目的，對於處理過程的步驟劃分和流程定義則是手段。因而處理流程規範化的首要內容就是考慮壹個通用的Servlet響應程序大致應該包含的邏輯步驟：
l?步驟1——?對Http請求進行初步處理，查找與之對應的Controller處理類（方法）——HandlerMapping
l?步驟2——?調用相應的Controller處理類（方法）完成業務邏輯——HandlerAdapter
l?步驟3——?對Controller處理類（方法）調用時可能發生的異常進行處理——HandlerExceptionResolver
l?步驟4——?根據Controller處理類（方法）的調用結果，進行Http響應處理——ViewResolver
正是這基於組件、接口的設計，支持了SpringMVC的另壹個特性：行為的可擴展性。
第三、設計原則更加明朗。
Open?for?extension?/closed?for?modification
這條重要的設計原則被寫在了Spring官方的reference中SpringMVC章節的起始段：?A?key?design?principle?in?SpringWeb?MVC?and?in?Spring?in?general?is?the?“Open?for?extension,?closed?for?modification”?principle.
並且重點很好地體現在SpringMVC的實現當中，可以擴展，但卻不能改變。我曾經擴展過Spring的IOC、AOP功能，這壹點SpringMVC應該和Spring壹脈相承。
第四、組件化的設計方案和特定的設計原則讓SpringMVC形散神聚。
神?——?SpringMVC總是沿著壹條固定的邏輯主線運行
形?——?SpringMVC卻擁有多種不同的行為模式
SpringMVC是壹個基於組件的開發框架，組件的不同實現體系構成了“形”；組件的邏輯串聯構成了“神”。因此，“形散神不散”：?SpringMVC的邏輯主線始終不變，而行為模式卻可以多種多樣。
第五、更加貼合Web發展的趨勢，這個更加虛了，不再展開說這個?問題了。
第六、技術上的放緩導致了程序員對Struts2失去了熱情，導致SpringMVC依靠自身的努力和Spring的口碑，逐漸顯露了自身的優勢和特點。
為什麽SpringMVC會贏得最後的勝利呢？最後，我們不妨想壹想Struts2是怎樣流行起來的！
我自己是從Struts1用過來的，後來Struts1的問題很明顯了，開源社區出現了很多的MVC框架，最為突出的是Webwork2。
Webwork2探索了壹條與傳統Servlet模型不同的解決方案，逐漸被大家熟識和理解，不斷發展並得到了廣大程序員的認可。它以優秀的設計思想和靈活的實現，吸引了大批的Web層開發人員投入它的?懷抱。
Apache社區與Opensymphony宣布未來的Struts項目將與Webwork2項目合並，並聯合推出Struts2。
Struts2能夠在壹個相當長的時間段內占據開發市場主導地位的重要原因在於其技術上的領先優勢。而這壹技術上的領先優勢，突出表現為對Controller的徹底改造：
public?class?UserController?{private?User?user
public?String?execute()?{
//?這裏加入業務邏輯代碼
return?"success";
}
}
從上面的代碼中，我們可以看到Webwork2?/Struts2對於Controller最大的改造有兩點：
在Controller中徹底杜絕引入HttpServletRequest或者HttpServletResponse這樣的原生Servlet對象。
將請求參數和響應數據都從響應方法中剝離到了Controller中的屬性變量。
這兩大改造被看作是框架的神來之筆。因為通過這壹改造，整個Controller類徹底與Web容器解耦，可以方便地進行單元測試。而擺脫了Servlet束縛的Controller，也為整個編程模型賦予了全新的定義。從引入新的編程元素的角度來說，Webwork2?/?Struts2無疑也是成功的。因為在傳統Servlet模式中的禁地Controller中的屬性變量被合理利用了起來作為請求處理過程中的數據部分。這樣的改造不僅使得表達式引擎能夠得到最大限度的發揮，同時使得整個Controller看起來更像是壹個POJO。因而，這種表現形態被筆者冠以的名稱?是：POJO實現模式。POJO實現模式是壹種具有革命性意義的模式，因為它能夠把解耦合這樣壹個觀點發揮到極致。從面向對象的角度來看，POJO模式無疑也是所有程序員所追求的壹個目標。這也就是Webwork2?/Struts2那麽多年來經久不衰的壹個重要原因。
所以，我們看到第壹條原因是Struts2依靠技術上的革新贏得了程序員的青睞。但是，這些年來Struts2在技術革新上的作為似乎步子就邁得比較小。我們可以看到，在JDK1.5普及之後，Annotation作為壹種新興的Java語法，逐漸?被大家熟知和應用。這壹點上SpringMVC緊跟了時代的潮流，直接用於請求-響應的映射。而Struts2卻遲遲無法在單壹配置源的問題上形成突破。?當然，這只是技術革新上的壹個簡單的例子，其他的例子還有很多。
至少給人的感覺是這樣的。在這壹點上Struts並不是很沾光，因為Spring的口碑和影響力也客觀程度上加深了大家對SpirngMVC是技術領導者的印象。