下面這些東西基本都是我從網(wǎng)上粘貼過來的，沒有那么多耐心和時間一個字一個字的敲了，但是基本能表明我選擇SPRingMVC的思路和原因。

把這張圖放在這里，我是想說SpringMVC和Struts2真的是不一樣的，雖然在都有著核心分發(fā)器等相同的功能組件（這些由MVC模式本身決定的）。

為什么SpringMVC會贏得最后的勝利呢？談幾點我自己的看法：

第一、MVC框架的出現(xiàn)是為了將URL從HTTP的世界中映射到java世界中，這是MVC框架的核心功能。而在URL這一點SpringMVC無疑更加優(yōu)雅。

第二、從設(shè)計實現(xiàn)角度來說，我覺得SpringMVC更加清晰。即使我們?nèi)Ρ萐truts2的原理圖和SpringMVC的類圖，它依然很讓人困惑，遠(yuǎn)沒有SpringMVC更加直觀：

SpringMVC設(shè)計思路：將整個處理流程規(guī)范化，并把每一個處理步驟分派到不同的組件中進(jìn)行處理。

這個方案實際上涉及到兩個方面：

l 處理流程規(guī)范化 —— 將處理流程劃分為若干個步驟（任務(wù)），并使用一條明確的邏輯主線將所有的步驟串聯(lián)起來

l 處理流程組件化 —— 將處理流程中的每一個步驟（任務(wù)）都定義為接口，并為每個接口賦予不同的實現(xiàn)模式

處理流程規(guī)范化是目的，對于處理過程的步驟劃分和流程定義則是手段。因而處理流程規(guī)范化的首要內(nèi)容就是考慮一個通用的Servlet響應(yīng)程序大致應(yīng)該包含的邏輯步驟：

l 步驟1—— 對Http請求進(jìn)行初步處理，查找與之對應(yīng)的Controller處理類（方法）   ——HandlerMapping

l 步驟2—— 調(diào)用相應(yīng)的Controller處理類（方法）完成業(yè)務(wù)邏輯                    ——HandlerAdapter

l 步驟3—— 對Controller處理類（方法）調(diào)用時可能發(fā)生的異常進(jìn)行處理            ——HandlerExceptionResolver

l 步驟4—— 根據(jù)Controller處理類（方法）的調(diào)用結(jié)果，進(jìn)行Http響應(yīng)處理       ——ViewResolver

正是這基于組件、接口的設(shè)計，支持了SpringMVC的另一個特性：行為的可擴(kuò)展性。

第三、設(shè)計原則更加明朗。

    【Open for extension /closed for modification】

這條重要的設(shè)計原則被寫在了spring官方的reference中SpringMVC章節(jié)的起始段： A key design principle in SpringWeb MVC and in Spring in general is the “Open for extension, closed for modification” principle.

并且重點很好地體現(xiàn)在SpringMVC的實現(xiàn)當(dāng)中，可以擴(kuò)展，但卻不能改變。我曾經(jīng)擴(kuò)展過Spring的IOC、AOP功能，這一點SpringMVC應(yīng)該和Spring一脈相承。

第四、組件化的設(shè)計方案和特定的設(shè)計原則讓SpringMVC形散神聚。

SpringMVC是一個基于組件的開發(fā)框架，組件的不同實現(xiàn)體系構(gòu)成了“形”；組件的邏輯串聯(lián)構(gòu)成了“神”。因此，“形散神不散”： SpringMVC的邏輯主線始終不變，而行為模式卻可以多種多樣。

第五、更加貼合Web發(fā)展的趨勢，這個更加虛了，不再展開說這個 問題了。

第六、技術(shù)上的放緩導(dǎo)致了程序員對Struts2失去了熱情，導(dǎo)致SpringMVC依靠自身的努力和Spring的口碑，逐漸顯露了自身的優(yōu)勢和特點。

為什么SpringMVC會贏得最后的勝利呢？最后，我們不妨想一想Struts2是怎樣流行起來的！

我自己是從Struts1用過來的，后來Struts1的問題很明顯了，開源社區(qū)出現(xiàn)了很多的MVC框架，最為突出的是Webwork2。

Webwork2探索了一條與傳統(tǒng)Servlet模型不同的解決方案，逐漸被大家熟識和理解，不斷發(fā)展并得到了廣大程序員的認(rèn)可。它以優(yōu)秀的設(shè)計思想和靈活的實現(xiàn)，吸引了大批的Web層開發(fā)人員投入它的 懷抱。

Apache社區(qū)與Opensymphony宣布未來的Struts項目將與Webwork2項目合并，并聯(lián)合推出Struts2。

Struts2能夠在一個相當(dāng)長的時間段內(nèi)占據(jù)開發(fā)市場主導(dǎo)地位的重要原因在于其技術(shù)上的領(lǐng)先優(yōu)勢。而這一技術(shù)上的領(lǐng)先優(yōu)勢，突出表現(xiàn)為對Controller的徹底改造：

public class UserController {

    private User user

    public String execute() {

        // 這里加入業(yè)務(wù)邏輯代碼

       return "success";

    }

}

從上面的代碼中，我們可以看到Webwork2 /Struts2對于Controller最大的改造有兩點：

這兩大改造被看作是框架的神來之筆。因為通過這一改造，整個Controller類徹底與Web容器解耦，可以方便地進(jìn)行單元測試。而擺脫了Servlet束縛的Controller，也為整個編程模型賦予了全新的定義。從引入新的編程元素的角度來說，Webwork2 / Struts2無疑也是成功的。因為在傳統(tǒng)Servlet模式中的禁地Controller中的屬性變量被合理利用了起來作為請求處理過程中的數(shù)據(jù)部分。這樣的改造不僅使得表達(dá)式引擎能夠得到最大限度的發(fā)揮，同時使得整個Controller看起來更像是一個POJO。因而，這種表現(xiàn)形態(tài)被筆者冠以的名稱 是：POJO實現(xiàn)模式。POJO實現(xiàn)模式是一種具有革命性意義的模式，因為它能夠把解耦合這樣一個觀點發(fā)揮到極致。從面向?qū)ο蟮慕嵌葋砜矗琍OJO模式無疑也是所有程序員所追求的一個目標(biāo)。這也就是Webwork2 /Struts2那么多年來經(jīng)久不衰的一個重要原因。

所以，我們看到第一條原因是Struts2依靠技術(shù)上的革新贏得了程序員的青睞。但是，這些年來Struts2在技術(shù)革新上的作為似乎步子就邁得比較小。我們可以看到，在JDK1.5普及之后，Annotation作為一種新興的Java語法，逐漸 被大家熟知和應(yīng)用。這一點上SpringMVC緊跟了時代的潮流，直接用于請求-響應(yīng)的映射。而Struts2卻遲遲無法在單一配置源的問題上形成突破。 當(dāng)然，這只是技術(shù)革新上的一個簡單的例子，其他的例子還有很多。

至少給人的感覺是這樣的。在這一點上Struts并不是很沾光，因為Spring的口碑和影響力也客觀程度上加深了大家對SpirngMVC是技術(shù)領(lǐng)導(dǎo)者的印象。