SpringMVC原始碼分析1：SpringMVC概述

轉自： 跟開濤學SpringMVC

Web MVC簡介

Web開發中的請求-響應模型：

在Web世界裡，具體步驟如下：

1、  Web瀏覽器（如IE）發起請求，如訪問 http://sishuok.com

2、  Web伺服器（如Tomcat）接收請求，處理請求（比如使用者新增，則將把使用者儲存一下），最後產生響應（一般為html）。

3、web伺服器處理完成後，返回內容給web客戶端（一般就是我們的瀏覽器），客戶端對接收的內容進行處理（如web瀏覽器將會對接收到的html內容進行渲染以展示給客戶）。

因此，在Web世界裡：

都是Web客戶端發起請求，Web伺服器接收、處理併產生響應。

一般Web伺服器是不能主動通知Web客戶端更新內容。雖然現在有些技術如伺服器推（如Comet）、還有現在的HTML5 websocket可以實現Web伺服器主動通知Web客戶端。

到此我們瞭解了在web開發時的請求/響應模型，接下來我們看一下標準的MVC模型是什麼。

標準MVC模型概述

**MVC模型：**是一種架構型的模式，本身不引入新功能，只是幫助我們將開發的結構組織的更加合理，使展示與模型分離、流程控制邏輯、業務邏輯呼叫與展示邏輯分離。如圖1-2

圖1-2

首先讓我們瞭解下MVC（Model-View-Controller）三元組的概念：

**Model（模型）：**資料模型，提供要展示的資料，因此包含資料和行為，可以認為是領域模型或JavaBean元件（包含資料和行為），不過現在一般都分離開來：Value Object（資料） 和 服務層（行為）。也就是模型提供了模型資料查詢和模型資料的狀態更新等功能，包括資料和業務。

**View（檢視）：**負責進行模型的展示，一般就是我們見到的使用者介面，客戶想看到的東西。

**Controller（控制器）：**接收使用者請求，委託給模型進行處理（狀態改變），處理完畢後把返回的模型資料返回給檢視，由檢視負責展示。 也就是說控制器做了個排程員的工作，。

從圖1-1我們還看到，在標準的MVC中模型能主動推資料給檢視進行更新（觀察者設計模式，在模型上註冊檢視，當模型更新時自動更新檢視），但在Web開發中模型是無法主動推給檢視（無法主動更新使用者介面），因為在Web開發是請求-響應模型。

那接下來我們看一下在Web裡MVC是什麼樣子，我們稱其為 Web MVC 來區別標準的MVC。

Web MVC概述

模型-檢視-控制器概念和標準MVC概念一樣，請參考1.2，我們再看一下Web MVC標準架構，如圖1-3：

如圖1-3

在Web MVC模式下，模型無法主動推資料給檢視，如果使用者想要檢視更新，需要再傳送一次請求（即請求-響應模型）。

概念差不多了，我們接下來了解下Web端開發的發展歷程，和使用程式碼來演示一下Web MVC是如何實現的，還有為什麼要使用MVC這個模式呢？

Web端開發發展歷程

此處我們只是簡單的敘述比較核心的歷程，如圖1-4

圖1-4

1.4.1、CGI：（Common Gateway Interface）公共閘道器介面，一種在web服務端使用的指令碼技術，使用C或Perl語言編寫，用於接收web使用者請求並處理，最後動態產生響應給使用者，但每次請求將產生一個程式，重量級。

1.4.2、Servlet：一種JavaEE web元件技術，是一種在伺服器端執行的web元件，用於接收web使用者請求並處理，最後動態產生響應給使用者。但每次請求只產生一個執行緒（而且有執行緒池），輕量級。而且能利用許多JavaEE技術（如JDBC等）。本質就是在java程式碼裡面 輸出 html流。但表現邏輯、控制邏輯、業務邏輯呼叫混雜。如圖1-5

圖1-5

如圖1-5，這種做法是絕對不可取的，控制邏輯、表現程式碼、業務邏輯物件呼叫混雜在一起，最大的問題是直接在Java程式碼裡面輸出Html，這樣前端開發人員無法進行頁面風格等的設計與修改，即使修改也是很麻煩，因此實際專案這種做法不可取。

1.4.3、JSP：（Java Server Page）：一種在伺服器端執行的web元件，是一種執行在標準的HTML頁面中嵌入指令碼語言（現在只支援Java）的模板頁面技術。本質就是在html程式碼中嵌入java程式碼。JSP最終還是會被編譯為Servlet，只不過比純Servlet開發頁面更簡單、方便。但表現邏輯、控制邏輯、業務邏輯呼叫還是混雜。如圖1-6

圖1-6

如圖1-6，這種做法也是絕對不可取的，控制邏輯、表現程式碼、業務邏輯物件呼叫混雜在一起，但比直接在servlet裡輸出html要好一點，前端開發人員可以進行簡單的頁面風格等的設計與修改（但如果嵌入的java指令碼太多也是很難修改的），因此實際專案這種做法不可取。

JSP本質還是Servlet，最終在執行時會生成一個Servlet（如tomcat，將在tomcat\work\Catalina\web應用名\org\apache\jsp下生成），但這種使得寫html簡單點，但仍是控制邏輯、表現程式碼、業務邏輯物件呼叫混雜在一起。

**1.4.4、Model1：**可以認為是JSP的增強版，可以認為是jsp+javabean如圖1-7

特點：使用 jsp:useBean標準動作，自動將請求引數封裝為JavaBean元件；還必須使用java指令碼執行控制邏輯。

圖1-7

此處我們可以看出，使用 jsp:useBean標準動作可以簡化javabean的獲取/建立，及將請求引數封裝到javabean，再看一下Model1架構，如圖1-8。

圖1-8 Model1架構

Model1架構中，JSP負責控制邏輯、表現邏輯、業務物件（javabean）的呼叫，只是比純JSP簡化了獲取請求引數和封裝請求引數。同樣是不好的，在專案中應該嚴禁使用（或最多再demo裡使用）。

1.4.5、Model2： 在JavaEE世界裡，它可以認為就是Web MVC模型

Model2架構其實可以認為就是我們所說的Web MVC模型，只是控制器採用Servlet、模型採用JavaBean、檢視採用JSP，如圖1-9

圖1-9 Model2架構

具體程式碼事例如下：

從Model2架構可以看出，檢視和模型分離了，控制邏輯和展示邏輯分離了。

但我們也看到嚴重的缺點：

1．  1、控制器：

1．1．1、控制邏輯可能比較複雜，其實我們可以按照規約，如請求引數submitFlag=toAdd，我們其實可以直接呼叫toAdd方法，來簡化控制邏輯；而且每個模組基本需要一個控制器，造成控制邏輯可能很複雜；

1．1．2、請求引數到模型的封裝比較麻煩，如果能交給框架來做這件事情，我們可以從中得到解放；

1．1．3、選擇下一個檢視，嚴重依賴Servlet API，這樣很難或基本不可能更換檢視；

1．1．4、給檢視傳輸要展示的模型資料，使用Servlet API，更換檢視技術也要一起更換，很麻煩。

1.2、模型：

1．2．1、此處模型使用JavaBean，可能造成JavaBean元件類很龐大，一般現在專案都是採用三層架構，而不採用JavaBean。

1.3、檢視

1．3．1、現在被繫結在JSP，很難更換檢視，比如Velocity、FreeMarker；比如我要支援Excel、PDF檢視等等。

1.4.5、服務到工作者：Front Controller + Application Controller + Page Controller + Context

即，前端控制器+應用控制器+頁面控制器（也有稱其為動作）+上下文，也是Web MVC，只是責任更加明確，詳情請參考《核心J2EE設計模式》和《企業應用架構模式》如圖1-10：

圖1-10

執行流程如下：

職責：

**Front Controller：**前端控制器，負責為表現層提供統一訪問點，從而避免Model2中出現的重複的控制邏輯（由前端控制器統一回撥相應的功能方法，如前邊的根據submitFlag=login轉調login方法）；並且可以為多個請求提供共用的邏輯（如準備上下文等等），將選擇具體檢視和具體的功能處理（如login裡邊封裝請求引數到模型，並呼叫業務邏輯物件）分離。

**Application Controller：**應用控制器，前端控制器分離選擇具體檢視和具體的功能處理之後，需要有人來管理，應用控制器就是用來選擇具體檢視技術（檢視的管理）和具體的功能處理（頁面控制器/命令物件/動作管理），一種策略設計模式的應用，可以很容易的切換檢視/頁面控制器，相互不產生影響。

**Page Controller(Command)：**頁面控制器/動作/處理器：功能處理程式碼，收集引數、封裝引數到模型，轉調業務物件處理模型，返回邏輯檢視名交給前端控制器（和具體的檢視技術解耦），由前端控制器委託給應用控制器選擇具體的檢視來展示，可以是命令設計模式的實現。頁面控制器也被稱為處理器或動作。

**Context：**上下文，還記得Model2中為檢視準備要展示的模型資料嗎，我們直接放在request中（Servlet API相關），有了上下文之後，我們就可以將相關資料放置在上下文，從而與協議無關（如Servlet API）的訪問/設定模型資料，一般通過ThreadLocal模式實現。

到此，我們回顧了整個web開發架構的發展歷程，可能不同的web層框架在細節處理方面不同，但的目的是一樣的：

乾淨的web表現層：

模型和檢視的分離；

控制器中的控制邏輯與功能處理分離（收集並封裝引數到模型物件、業務物件呼叫）；

控制器中的檢視選擇與具體檢視技術分離。

輕薄的web表現層：

做的事情越少越好，薄薄的，不應該包含無關程式碼；

只負責收集並組織引數到模型物件，啟動業務物件的呼叫；

控制器只返回邏輯檢視名並由相應的應用控制器來選擇具體使用的檢視策略；

儘量少使用框架特定API，保證容易測試。

到此我們瞭解Web MVC的發展歷程，接下來讓我們瞭解下Spring MVC到底是什麼、架構及來個HelloWorld瞭解下具體怎麼使用吧。

本章具體程式碼請參考 springmvc-chapter1工程。

Spring Web MVC是什麼

Spring Web MVC是一種基於Java的實現了Web MVC設計模式的請求驅動型別的輕量級Web框架，即使用了MVC架構模式的思想，將web層進行職責解耦，基於請求驅動指的就是使用請求-響應模型，框架的目的就是幫助我們簡化開發，Spring Web MVC也是要簡化我們日常Web開發的。

另外還有一種基於元件的、事件驅動的Web框架在此就不介紹了，如Tapestry、JSF等。

Spring Web MVC也是服務到工作者模式的實現，但進行可優化。前端控制器是 DispatcherServlet；應用控制器其實拆為處理器對映器(Handler Mapping)進行處理器管理和檢視解析器(View Resolver)進行檢視管理；頁面控制器/動作/處理器為Controller介面（僅包含 ModelAndView handleRequest(request, response) 方法）的實現（也可以是任何的POJO類）；支援本地化（Locale）解析、主題（Theme）解析及檔案上傳等；提供了非常靈活的資料驗證、格式化和資料繫結機制；提供了強大的約定大於配置（慣例優先原則）的契約式程式設計支援。

Spring Web MVC能幫我們做什麼

√讓我們能非常簡單的設計出乾淨的Web層和薄薄的Web層；

√進行更簡潔的Web層的開發；

√天生與Spring框架整合（如IoC容器、AOP等）；

√提供強大的約定大於配置的契約式程式設計支援；

√能簡單的進行Web層的單元測試；

√支援靈活的URL到頁面控制器的對映；

√非常容易與其他檢視技術整合，如Velocity、FreeMarker等等，因為模型資料不放在特定的API裡，而是放在一個Model裡（ Map資料結構實現，因此很容易被其他框架使用）；

√非常靈活的資料驗證、格式化和資料繫結機制，能使用任何物件進行資料繫結，不必實現特定框架的API；

√提供一套強大的JSP標籤庫，簡化JSP開發；

√支援靈活的本地化、主題等解析；

√更加簡單的異常處理；

√對靜態資源的支援；

√支援Restful風格。

Spring Web MVC架構

Spring Web MVC框架也是一個基於請求驅動的Web框架，並且也使用了前端控制器模式來進行設計，再根據請求對映規則分發給相應的頁面控制器（動作/處理器）進行處理。首先讓我們整體看一下Spring Web MVC處理請求的流程：

Spring Web MVC處理請求的流程

如圖2-1

圖2-1

具體執行步驟如下：

1、  首先使用者傳送請求————>前端控制器，前端控制器根據請求資訊（如URL）來決定選擇哪一個頁面控制器進行處理並把請求委託給它，即以前的控制器的控制邏輯部分；圖2-1中的1、2步驟；

2、  頁面控制器接收到請求後，進行功能處理，首先需要收集和繫結請求引數到一個物件，這個物件在Spring Web MVC中叫命令物件，並進行驗證，然後將命令物件委託給業務物件進行處理；處理完畢後返回一個ModelAndView（模型資料和邏輯檢視名）；圖2-1中的3、4、5步驟；

3、  前端控制器收回控制權，然後根據返回的邏輯檢視名，選擇相應的檢視進行渲染，並把模型資料傳入以便檢視渲染；圖2-1中的步驟6、7；

4、  前端控制器再次收回控制權，將響應返回給使用者，圖2-1中的步驟8；至此整個結束。

問題：

1、  請求如何給前端控制器？

2、  前端控制器如何根據請求資訊選擇頁面控制器進行功能處理？

3、  如何支援多種頁面控制器呢？

4、  如何頁面控制器如何使用業務物件？

5、  頁面控制器如何返回模型資料？

6、  前端控制器如何根據頁面控制器返回的邏輯檢視名選擇具體的檢視進行渲染？

7、  不同的檢視技術如何使用相應的模型資料？

首先我們知道有如上問題，那這些問題如何解決呢？請讓我們先繼續，在後邊依次回答。

Spring Web MVC架構

1、Spring Web MVC核心架構圖，如圖2-2

圖2-2

架構圖對應的DispatcherServlet核心程式碼如下：

java程式碼：

//前端控制器分派方法  
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {  
        HttpServletRequest processedRequest = request;  
        HandlerExecutionChain mappedHandler = null;  
        int interceptorIndex = -1;  
  
        try {  
            ModelAndView mv;  
            boolean errorView = false;  
  
            try {  
                   //檢查是否是請求是否是multipart（如檔案上傳），如果是將通過MultipartResolver解析  
                processedRequest = checkMultipart(request);  
                   //步驟2、請求到處理器（頁面控制器）的對映，通過HandlerMapping進行對映  
                mappedHandler = getHandler(processedRequest, false);  
                if (mappedHandler == null || mappedHandler.getHandler() == null) {  
                    noHandlerFound(processedRequest, response);  
                    return;  
                }  
                   //步驟3、處理器適配，即將我們的處理器包裝成相應的介面卡（從而支援多種型別的處理器）  
                HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());  
  
                  // 304 Not Modified快取支援  
                //此處省略具體程式碼  
  
                // 執行處理器相關的攔截器的預處理（HandlerInterceptor.preHandle）  
                //此處省略具體程式碼  
  
                // 步驟4、由介面卡執行處理器（呼叫處理器相應功能處理方法）  
                mv = ha.handle(processedRequest, response, mappedHandler.getHandler());  
  
                // Do we need view name translation?  
                if (mv != null && !mv.hasView()) {  
                    mv.setViewName(getDefaultViewName(request));  
                }  
  
                // 執行處理器相關的攔截器的後處理（HandlerInterceptor.postHandle）  
                //此處省略具體程式碼  
            }  
            catch (ModelAndViewDefiningException ex) {  
                logger.debug("ModelAndViewDefiningException encountered", ex);  
                mv = ex.getModelAndView();  
            }  
            catch (Exception ex) {  
                Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);  
                mv = processHandlerException(processedRequest, response, handler, ex);  
                errorView = (mv != null);  
            }  
  
            //步驟5 步驟6、解析檢視並進行檢視的渲染  
//步驟5 由ViewResolver解析View（viewResolver.resolveViewName(viewName, locale)）  
//步驟6 檢視在渲染時會把Model傳入（view.render(mv.getModelInternal(), request, response);）  
            if (mv != null && !mv.wasCleared()) {  
                render(mv, processedRequest, response);  
                if (errorView) {  
                    WebUtils.clearErrorRequestAttributes(request);  
                }  
            }  
            else {  
                if (logger.isDebugEnabled()) {  
                    logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() +  
                            "': assuming HandlerAdapter completed request handling");  
                }  
            }  
  
            // 執行處理器相關的攔截器的完成後處理（HandlerInterceptor.afterCompletion）  
            //此處省略具體程式碼  
  
  
        catch (Exception ex) {  
            // Trigger after-completion for thrown exception.  
            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);  
            throw ex;  
        }  
        catch (Error err) {  
            ServletException ex = new NestedServletException("Handler processing failed", err);  
            // Trigger after-completion for thrown exception.  
            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);  
            throw ex;  
        }  
  
        finally {  
            // Clean up any resources used by a multipart request.  
            if (processedRequest != request) {  
                cleanupMultipart(processedRequest);  
            }  
        }  
    }

核心架構的具體流程步驟如下：

1、  首先使用者傳送請求——>DispatcherServlet，前端控制器收到請求後自己不進行處理，而是委託給其他的解析器進行處理，作為統一訪問點，進行全域性的流程控制；

2、  DispatcherServlet——>HandlerMapping， HandlerMapping將會把請求對映為HandlerExecutionChain物件（包含一個Handler處理器（頁面控制器）物件、多個HandlerInterceptor攔截器）物件，通過這種策略模式，很容易新增新的對映策略；

3、  DispatcherServlet——>HandlerAdapter，HandlerAdapter將會把處理器包裝為介面卡，從而支援多種型別的處理器，即介面卡設計模式的應用，從而很容易支援很多型別的處理器；

4、  HandlerAdapter——>處理器功能處理方法的呼叫，HandlerAdapter將會根據適配的結果呼叫真正的處理器的功能處理方法，完成功能處理；並返回一個ModelAndView物件（包含模型資料、邏輯檢視名）；

5、  ModelAndView的邏輯檢視名——> ViewResolver， ViewResolver將把邏輯檢視名解析為具體的View，通過這種策略模式，很容易更換其他檢視技術；

6、  View——>渲染，View會根據傳進來的Model模型資料進行渲染，此處的Model實際是一個Map資料結構，因此很容易支援其他檢視技術；

7、返回控制權給DispatcherServlet，由DispatcherServlet返回響應給使用者，到此一個流程結束。

此處我們只是講了核心流程，沒有考慮攔截器、本地解析、檔案上傳解析等，後邊再細述。

到此，再來看我們前邊提出的問題：

1、  請求如何給前端控制器？這個應該在web.xml中進行部署描述，在HelloWorld中詳細講解。

2、  前端控制器如何根據請求資訊選擇頁面控制器進行功能處理？ 我們需要配置HandlerMapping進行對映

3、  如何支援多種頁面控制器呢？配置HandlerAdapter從而支援多種型別的頁面控制器

4、  如何頁面控制器如何使用業務物件？可以預料到，肯定利用Spring IoC容器的依賴注入功能

5、  頁面控制器如何返回模型資料？使用ModelAndView返回

6、  前端控制器如何根據頁面控制器返回的邏輯檢視名選擇具體的檢視進行渲染？ 使用ViewResolver進行解析

7、  不同的檢視技術如何使用相應的模型資料？ 因為Model是一個Map資料結構，很容易支援其他檢視技術

在此我們可以看出具體的核心開發步驟：

1、  DispatcherServlet在web.xml中的部署描述，從而攔截請求到Spring Web MVC

2、  HandlerMapping的配置，從而將請求對映到處理器

3、  HandlerAdapter的配置，從而支援多種型別的處理器

4、  ViewResolver的配置，從而將邏輯檢視名解析為具體檢視技術

5、處理器（頁面控制器）的配置，從而進行功能處理

上邊的開發步驟我們會在Hello World中詳細驗證。

Spring Web MVC優勢

1、清晰的角色劃分：前端控制器（ DispatcherServlet）、請求到處理器對映（HandlerMapping）、處理器介面卡（HandlerAdapter）、檢視解析器（ViewResolver）、處理器或頁面控制器（Controller）、驗證器（   Validator）、命令物件（Command  請求引數繫結到的物件就叫命令物件）、表單物件（Form Object 提供給表單展示和提交到的物件就叫表單物件）。

2、分工明確，而且擴充套件點相當靈活，可以很容易擴充套件，雖然幾乎不需要；

3、由於命令物件就是一個POJO，無需繼承框架特定API，可以使用命令物件直接作為業務物件；

4、和Spring 其他框架無縫整合，是其它Web框架所不具備的；

5、可適配，通過HandlerAdapter可以支援任意的類作為處理器；

6、可定製性，HandlerMapping、ViewResolver等能夠非常簡單的定製；

7、功能強大的資料驗證、格式化、繫結機制；

8、利用Spring提供的Mock物件能夠非常簡單的進行Web層單元測試；

9、本地化、主題的解析的支援，使我們更容易進行國際化和主題的切換。

10、強大的JSP標籤庫，使JSP編寫更容易。

………………還有比如RESTful風格的支援、簡單的檔案上傳、約定大於配置的契約式程式設計支援、基於註解的零配置支援等等。

DispatcherServlet作用

DispatcherServlet是前端控制器設計模式的實現，提供Spring Web MVC的集中訪問點，而且負責職責的分派，而且與Spring IoC容器無縫整合，從而可以獲得Spring的所有好處。 具體請參考第二章的圖2-1。

DispatcherServlet主要用作職責排程工作，本身主要用於控制流程，主要職責如下：

1、檔案上傳解析，如果請求型別是multipart將通過MultipartResolver進行檔案上傳解析；

2、通過HandlerMapping，將請求對映到處理器（返回一個HandlerExecutionChain，它包括一個處理器、多個HandlerInterceptor攔截器）；

3、通過HandlerAdapter支援多種型別的處理器(HandlerExecutionChain中的處理器)；

4、通過ViewResolver解析邏輯檢視名到具體檢視實現；

5、本地化解析；

6、渲染具體的檢視等；

7、如果執行過程中遇到異常將交給HandlerExceptionResolver來解析。

從以上我們可以看出DispatcherServlet主要負責流程的控制（而且在流程中的每個關鍵點都是很容易擴充套件的）。