1.1、Web開發中的請求-響應模型：
在Web世界裡： 都是Web客戶端發起請求，Web服務器接收、處理併產生響應。 一般Web服務器是不能主動通知Web客戶端更新內容。雖然現在有些技術如服務器推（如Comet）、還有現在的HTML5 websocket可以實現Web服務器主動通知Web客戶端。
1.2、標準MVC模型概述
MVC模型：是一種架構型的模式，本身不引入新功能，只是幫助我們將開發的結構組織的更加合理，使展示與模型分離、流程控制邏輯、業務邏輯調用與展示邏輯分離。如圖1-2
Model（模型）：數據模型，提供要展示的數據，因此包含數據和行為，可以認為是領域模型或JavaBean組件（包含數據和行為），不過現在一般都分離開來：Value Object（數據） 和 服務層（行為）。也就是模型提供了模型數據查詢和模型數據的狀態更新等功能，包括數據和業務。
View（視圖）：負責進行模型的展示，一般就是我們見到的用戶界面，客戶想看到的東西。
Controller（控制器）：接收用戶請求，委託給模型進行處理（狀態改變），處理完畢後把返回的模型數據返回給視圖，由視圖負責展示。 也就是說控制器做了個調度員的工作。
從圖1-2我們還看到，在標準的MVC中模型能主動推數據給視圖進行更新（觀察者設計模式，在模型上註冊視圖，當模型更新時自動更新視圖），但在Web開發中模型是無法主動推給視圖（無法主動更新用戶界面），因為在Web開發是請求-響應模型。
1.3、Web MVC概述
模型-視圖-控制器概念和標準MVC概念一樣，請參考1.2，我們再看一下Web MVC標準架構，如圖1-3：
在Web MVC模式下，模型無法主動推數據給視圖，如果用戶想要視圖更新，需要再發送一次請求（即請求-響應模型）。
1.4、Web端開發發展歷程
此處我們只是簡單的敘述比較核心的歷程，如圖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流。但這種做法是絕對不可取的，控制邏輯、表現代碼、業務邏輯對象調用混雜在一起，最大的問題是直接在Java代碼裡面輸出Html，這樣前端開發人員無法進行頁面風格等的設計與修改，即使修改也是很麻煩，因此實際項目這種做法不可取。1.4.3、JSP：（Java Server Page）：一種在服務器端執行的web組件，是一種運行在標準的HTML頁面中嵌入腳本語言（現在只支持Java）的模板頁面技術。本質就是在html代碼中嵌入java代碼。JSP本質還是Servlet，最終在運行時會生成一個Servlet（如tomcat，將在tomcatworkCatalinaweb應用名 orgapachejsp下生成），只是純Servlet開發頁面更簡單些。但這種做法也是絕對不可取的，控制邏輯、表現代碼、業務邏輯對象調用混雜在一起，但比直接在servlet裡輸出html要好一點，前端開發可以進行簡單的頁面風格等的設計與修改（但如果嵌入的java腳本太多也是很難修改的），實際項目這種做法也不可取。
1.4.4、Model1：可以認為是JSP的增強版，可以認為是jsp+javabean； 特點：使用
1.4.5、Model2：在JavaEE世界裡，它可以認為就是Web MVC模型
Model2架構其實可以認為就是我們所說的Web MVC模型，只是控制器採用Servlet、模型採用JavaBean、視圖採用JSP；
1.4.6、服務到工作者：Front Controller + Application Controller + Page Controller + Context
即，前端控制器+應用控制器+頁面控制器（也有稱其為動作）+上下文，也是Web MVC，只是責任更加明確，詳情請參考《核心J2EE設計模式》和《企業應用架構模式》如圖1-10：
運行流程如下：
Front Controller：前端控制器，負責為表現層提供統一訪問點，從而避免Model2中出現的重複的控制邏輯（由前端控制器統一回調相應的功能方法，如前邊的根據submitFlag=login轉調login方法）；並且可以為多個請求提供共用的邏輯（如準備上下文等等），將選擇具體視圖和具體的功能處理（如login裡邊封裝請求參數到模型，並調用業務邏輯對象）分離。
Application Controller：應用控制器，前端控制器分離選擇具體視圖和具體的功能處理之後，需要有人來管理，應用控制器就是用來選擇具體視圖技術（視圖的管理）和具體的功能處理（頁面控制器/命令對象/動作管理），一種策略設計模式的應用，可以很容易的切換視圖/頁面控制器，相互不產生影響。
Page Controller(Command)：頁面控制器/動作/處理器：功能處理代碼，收集參數、封裝參數到模型，轉調業務對象處理模型，返回邏輯視圖名交給前端控制器（和具體的視圖技術解耦），由前端控制器委託給應用控制器選擇具體的視圖來展示，可以是命令設計模式的實現。頁面控制器也被稱為處理器或動作。
Context：上下文，還記得Model2中為視圖準備要展示的模型數據嗎，我們直接放在request中（Servlet API相關），有了上下文之後，我們就可以將相關數據放置在上下文，從而與協議無關（如Servlet API）的訪問/設置模型數據，一般通過ThreadLocal模式實現。
2．1、Spring Web MVC
Spring Web MVC 是一種基於Java的實現了Web MVC設計模式的請求驅動類型的輕量級Web框架，即使用了MVC架構模式的思想，將web層進行職責解耦，基於請求驅動指的就是使用請求-響應模型。
Spring MVC 也是服務到工作者模式的實現，但進行可優化。 前端控制器是 DispatcherServlet；應用控制器其實拆為處理器映射器(Handler Mapping)進行處理器管理和視圖解析器(View Resolver)進行視圖管理；頁面控制器/動作/處理器為Controller接口（僅包含 方法） ModelAndView handleRequest(request, response) 的實現（可以是任何的POJO類）；支持本地化（Locale）解析、主題（Theme）解析及文件上傳等；提供了非常靈活的數據驗證、格式化和數據綁定機制；提供了強大的約定大於配置（慣例優先原則）的契約式編程支持。
Spring Web MVC架構
Spring Web MVC框架也是一個基於請求驅動的Web框架，並且也使用了前端控制器模式來進行設計，再根據請求映射規則分發給相應的頁面控制器（動作/處理器）進行處理。
Spring Web MVC處理請求的流程：
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；至此整個結束。
Spring MVC核心架構圖：
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返回響應給用戶，到此一個流程結束；
2．4、Spring 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風格的支持、簡單的文件上傳、約定大於配置的契約式編程支持、基於註解的零配置支持等等。
本文出自網上，由於頭條不能轉鏈接所以如果作者看到，請聯繫我
閱讀更多 互聯網Java架構 的文章
