下面這些東西基本都是我從網上粘貼過來的，沒有那么多耐心和時間一個字一個字的敲了，但是基本能表明我選擇SpringMVC的思路和原因。
把這張圖放在這里，我是想說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是技術領導者的印象。