轉自：http://www.cnblogs.com/dreamworlds/p/5396112.html
轉自：http://www.jianshu.com/p/baa3a05cd271
轉自：http://blog.csdn.net/binglumeng/article/details/53585821
從web.xml中servlet的配置開始，根據servlet攔截的url-pattern，進行請求轉發。
Spring MVC工作流程如下：


Spring工作流程如上圖所示：
1.使用者向伺服器傳送請求，請求被Spring前端控制Servlet DispatcherServlet捕獲；
2.DispatcherServlet對請求URL進行解析，得到請求資源識別符號(URI),呼叫HandlerMapping獲得該Handler配置的所有相關的物件(包括Handler物件以及Handler物件對應的攔截器)，最後以HandlerExecutionChain物件的形式返回；
3.DispatcherServlet根據獲得的Handler，選擇一個合適的HandlerAdapter。（如果成功獲得HandlerAdapter後，此時將開始執行攔截器的preHandler(…)方法）；
4.提取Request中的模型資料，填充Handler入參，開始執行Handler（Controller）。在填充Handler入參的過程中，根據你的配置，Spring幫你完成如下工作：
　　HttpMessageConveter：將請求訊息（如Json、xml等資料）轉換成一個物件，將物件轉換為指定的響應資訊
　　資料轉換：對請求訊息進行資料轉化。如String轉化成Integer、Double等；
　　資料驗證：驗證資料的有效性（長度、格式等），驗證結果儲存到BindingResult或Error中。
5.Handler執行完成後，向DispatcherServlet返回一個ModelAndView物件；
6.根據返回的ModelAndView，選擇一個合適的ViewResolver返回給DispatcherServlet；
7.ViewResolver結合Model和View，來渲染檢視；
8.將渲染結果返回給客戶端。

為什麼Spring只使用一個Servlet（DispatcherServlet）來處理所有請求？
主要原因由於J2EE核心模式-Font Controller（前端控制器）。Front Controller模式要求在WEB應用系統的前端（Front）設定一個入口控制器（Controller），所有的request請求都被髮往該控制器統一處理。Front Controller一般可以用來做一共同處理比如認證，頁面導航，Session管理，國際化或本地化處理等。在開發WEB應用系統（但不拘於WEB應用）時，存在很多不恰當的設計方法，比如讓客戶端（Client，一般指瀏覽器）可以直接訪問各個檢視（view，JSP等）。這樣邏輯被分散到各個檢視中，從而產生了各種問題：
1》對已有的功能修改困難，可維護性低。假如session管理，一旦session內容需要發生改變，則需要修改所有view中的相關程式碼。
2》很難增加新的功能，缺乏可擴充套件性。例如，需要在已有的系統中加入安全控制功能，控制使用者對某些頁面的訪問，因為沒有統一的處理入口，需要在所有的view中都加上認證程式碼。
使用Front Controller，強制分離view的顯示邏輯與業務處理邏輯。

Spring為什麼要結合使用HandlerMapping以及HnadlerAdapter來處理Handler？
主要原因是符合和麵向物件中單一職責原則，程式碼架構清晰，便於維護，程式碼可複用性高。如HandlerAdapter可能會被用於處理多種Hander。

1. 當DispatcherServlet接到請求時，他先回查詢適當的處理程式來處理請求。DispatcherServlet通過一個或者多個處理程式對映，將每個請求對映到處理程式中。處理程式對映配置在web應用程式的上下文中，是實現了HandlerMapping介面的Bean。它負責為請求返回一個適當的處理程式（也就是Controller）。處理程式對映通常根據請求的URL將請求對映到處理程式（Controller）。
2. 一旦DispatcherServlet選擇了適當的控制器，它就會呼叫這個控制器來處理請求。
3. 控制器處理完請求後，會將模型和檢視名（有時候是檢視物件）返回給DispatcherServlet。模型包含了控制器要傳遞給檢視進行顯示的屬性。如果返回的是檢視名稱，它會被解析成檢視物件再進行呈現。繫結模型和檢視的基本類是ModelAndView.
4. 當DispatcherServlet接收到模型和檢視名稱時，它會將邏輯檢視名稱解析成檢視物件再進行呈現。DispatcherServlet從一個或者多個檢視解析器中解析檢視。檢視解析器配置在Web應用程式上下文中，是實現了ViewResolver介面的Bean。它的任務是根據邏輯檢視名稱返回試圖物件。
5. 一旦DispatcherServlet將檢視名稱解析稱為檢視物件，它就會呈現檢視物件，並傳遞控制器返回的模型。檢視的任務是將模型屬性展示給使用者。

DispatcherServlet接收到請求後如何對映到Controller？
在Spring MVC中，web請求被Web應用程式上下文中宣告的一個或者多個處理程式對映Bean對映到Controller，Spring MVC提供了幾種HandlerMapping實現：
　　BeanNameUrlHandlerMapping(預設情況)，他根據Controller Bean名稱中指定的URL模式將請求對映到處理程式上。
eg. …
當你訪問http://**/welcome.htm這個URL時，DispatcherServlet通過BeanNameUrlHandlerMapping對映就找到了WelcomeController。
　　ControllerClassNameHandlerMapping，它是按控制器類名稱對映請求。
　　 SimpleUrlHandlerMapping，用定製的對映定義來對映請求。

Controller介面是Spring MVC中所有控制器類的基本介面。通過實現這個介面，你可以建立自己的控制器。在handleRequest()方法中，可以隨意地處理Web請求。
AbstractController:如果你想讓控制器具備一些基本的特性，如過濾受支援的HTTP方法（GET,POST和HEAD）,以及在HTTP響應中生成cache-control頭部等，你可以讓它擴充套件AbstractController類。
ParameterizableViewController:用來建立帶有引數化檢視的控制器。
SimpleFormController:它支援命令物件的概念（commandName），並且可以將表單域的值繫結到命令物件的同名屬性上。
AbstractWizardFormController:為嚮導表單的處理定義了基本的任務。嚮導表單有多個單頁，因此必須為嚮導表單控制器定義多個頁面檢視。然後這個控制器可以跨越所有這些表單頁面來管理表單狀態。嚮導表單會有多個動作，不像SimpleFormController只有單個提交動作。AbstractWizardFormController會根據特殊的請求引數決定使用者的動作，通常是用提交按鈕的名稱來指定動作的。
_finished: 完成嚮導表單。
_cancel: 取消嚮導表單。
_targetx: 進入目標頁面，這裡的x是從0開始的頁面索引。
MultiActionController：允許你將多個相關的動作分組到一個控制器中。
常見的檢視型別：

幾種常見的ViewResolver的解析：
InternalResourceViewResolver: 根據URL解析檢視。通過新增字首和字尾的方法，將每個檢視名稱都對映到一個URL上。
XmlViewResolver: 從XML配置檔案中解析檢視。將檢視宣告成Spring的Bean，並按他們的Bean Name進行解析。
ResourceBundleViewResolver: 從ResourceBundle中解析檢視。
用多個檢視解析器解析檢視, 需要注意的是，您需要為你配置的檢視解析器配置解析的優先順序。 value越小，優先順序越高。