Spring MVC體系結構

【Spring MVC類圖】
《Spring實戰》中：
《Spring3.0就這麼簡單》中：
【http://blog.csdn.net/gstormspire/article/details/8239182】
==========================================================================
 
Spring MVC在高併發狀況下性能更好，並且對代碼的侵入性不多，輕量級的緣由使得開發效率比Struts2好。
Spring MVC更加接近「零配置」的目標。
 
==========================================================================
 
——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
 
Struts2優點：
Struts2可以在一個至關長的時間段內佔據開發市場主導地位的重要緣由在於其技術上的領先優點。而這一技術上的領先優點，突出表現爲對Controller的完全改造：
public class UserController {
    private User user
    public String execute() {
        // 這裏加入業務邏輯代碼
       return "success";
    }
}
從上面的代碼中，咱們能夠看到Webwork2 /Struts2對於Controller最大的改造有兩點：
1.在Controller中完全杜絕引入HttpServletRequest或者HttpServletResponse這樣的原生Servlet對象。
2.將請求參數和響應數據都從響應方法中剝離到了Controller中的屬性變量。
 
整個Controller類完全與Web容器解耦，能夠方便地進行單元測試。
 
由於在傳統Servlet模式中的禁地Controller中的屬性變量被合理利用了起來做爲請求處理過程當中的數據部分。這樣的改造不只使得表達式引擎可以獲得最大限度的發揮，同時使得整個Controller看起來更像是一個POJO。於是，這種表現形態被筆者冠以的名稱是：POJO實現模式。POJO實現模式是一種具備革命性意義的模式，由於它可以把解耦合這樣一個觀點發揮到極致。從面向對象的角度來看，POJO模式無疑也是全部程序員所追求的一個目標。這也就是Webwork2 /Struts2那麼多年來經久不衰的一個重要緣由。
 
 
因此，咱們看到第一條緣由是Struts2依靠技術上的革新贏得了程序員的青睞。可是，這些年來Struts2在技術革新上的做爲彷佛步子就邁得比較小。咱們能夠看到，在JDK1.5普及以後，Annotation做爲一種新興的Java語法，逐漸被你們熟知和應用。這一點上SpringMVC緊跟了時代的潮流，直接用於請求-響應的映射。而Struts2卻遲遲沒法在單一配置源的問題上造成突破。固然，這只是技術革新上的一個簡單的例子，其餘的例子還有不少。
至少給人的感受是這樣的。在這一點上Struts並非很沾光，由於Spring的口碑和影響力也客觀程度上加深了你們對SpirngMVC是技術領導者的印象。
 
【注意】如今的struts2也有本身的註解。
 
==========================================================================
 
struts2是類級別的攔截，一個類對應一個request上下文。
springmvc是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應。因此說從架構自己上 spring3 mvc就容易實現restful url。
而struts2的架構實現起來要費勁，由於struts2 action的一個方法能夠對應一個url ，而其類屬性卻被全部方法共享，這也就沒法用註解或其餘方式標識其所屬方法了。
 
spring3mvc的方法之間基本上獨立的，獨享request response數據。請求數據經過參數獲取，處理結果經過ModelMap交回給框架。方法之間不共享變量。
而struts2搞的就比較亂，雖然方法之間也是獨立的，但其全部Action變量是共享的。這不會影響程序運行，卻給咱們編碼讀程序時帶來麻煩。 
 
spring3 mvc的驗證也是一個亮點，支持JSR303。處理ajax的請求更是方便只需一個註解@ResponseBody ，而後直接返回響應文本便可。
 
struts1也同樣，運行一個action的方法的時候建立一個action類，之後再運行就不會建立了，其實也是Servlet的封裝的框架。
struts2特殊一些，每一個請求要new一個action來保證線程安全。因此效率會低一些，可是不會低的特別離譜。
這樣也說明了spring3的mvc和struts1的mvc還有Servlet都是方法的線程安全，因此在類方法聲明的私有或者公有變量不是線程安全的。struts2的確實是線程安全的。
 
==========================================================================
 
1.spring mvc的入口是servlet，而struts2是filter
2.性能：spring會稍微比struts快。spring mvc是基於方法的設計，而sturts是基於類。
【基於類：是指一個URL請求對應於一個action類去處理】
【基於方法：一個請求對應類中的一個方法處理】
3. 參數傳遞：struts是在接受參數的時候，能夠用屬性來接受參數，這就說明參數是讓多個方法共享的。
4. 設計思想上：struts更加符合oop的編程思想， spring就比較謹慎，在servlet上擴展。
5. intercepter的實現機制：struts有以本身的interceptor機制，spring mvc用的是獨立的AOP方式。
6. 另外，spring3 mvc的驗證也是一個亮點，支持JSR303，處理ajax的請求更是方便，只需一個註解@ResponseBody ，而後直接返回響應文本便可。