Spring MVC詳解(適合Spring初學者)

第一章 Web MVC簡介

Web MVC簡介

1.一、Web開發中的請求-響應模型：

 

在Web世界裏，具體步驟以下：

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

二、  Web服務器（如Tomcat）接收請求，處理請求（好比用戶新增，則將把用戶保存一下），最後產生響應（通常爲html）。

三、web服務器處理完成後，返回內容給web客戶端（通常就是咱們的瀏覽器），客戶端對接收的內容進行處理（如web瀏覽器將會對接收到的html內容進行渲染以展現給客戶）。

 

所以，在Web世界裏：

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

 

通常Web服務器是不能主動通知Web客戶端更新內容。雖然如今有些技術如服務器推（如Comet）、還有如今的HTML5 websocket能夠實現Web服務器主動通知Web客戶端。

 

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

 

1.二、標準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。

1.三、Web MVC概述

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

 

如圖1-3

 

在Web MVC模式下，模型沒法主動推數據給視圖，若是用戶想要視圖更新，須要再發送一次請求（即請求-響應模型）。

 

概念差很少了，咱們接下來了解下Web端開發的發展歷程，和使用代碼來演示一下Web MVC是如何實現的，還有爲何要使用MVC這個模式呢？

 

1.四、Web端開發發展歷程

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

 

圖1-4

1.4.一、CGI：（Common Gateway Interface）公共網關接口，一種在web服務端使用的腳本技術，使用C或Perl語言編寫，用於接收web用戶請求並處理，最後動態產生響應給用戶，但每次請求將產生一個進程，重量級。

 

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

 

圖1-5

如圖1-5，這種作法是絕對不可取的，控制邏輯、表現代碼、業務邏輯對象調用混雜在一塊兒，最大的問題是直接在Java代碼裏面輸出Html，這樣前端開發人員沒法進行頁面風格等的設計與修改，即便修改也是很麻煩，所以實際項目這種作法不可取。

 

1.4.三、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.四、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.五、Model2：在JavaEE世界裏，它能夠認爲就是Web MVC模型

Model2架構其實能夠認爲就是咱們所說的Web MVC模型，只是控制器採用Servlet、模型採用JavaBean、視圖採用JSP，如圖1-9

 

圖1-9 Model2架構

 

具體代碼事例以下：

 

 

從Model2架構能夠看出，視圖和模型分離了，控制邏輯和展現邏輯分離了。

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

1．  一、控制器：

1．1．一、控制邏輯可能比較複雜，其實咱們能夠按照規約，如請求參數submitFlag=toAdd，咱們其實能夠直接調用toAdd方法，來簡化控制邏輯；並且每一個模塊基本須要一個控制器，形成控制邏輯可能很複雜；

1．1．二、請求參數到模型的封裝比較麻煩，若是能交給框架來作這件事情，咱們能夠從中獲得解放；

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

1．1．四、給視圖傳輸要展現的模型數據，使用Servlet API，更換視圖技術也要一塊兒更換，很麻煩。

 

1.二、模型：

1．2．一、此處模型使用JavaBean，可能形成JavaBean組件類很龐大，通常如今項目都是採用三層架構，而不採用JavaBean。

 

 

1.三、視圖

1．3．一、如今被綁定在JSP，很難更換視圖，好比Velocity、FreeMarker；好比我要支持Excel、PDF視圖等等。

 

1.4.五、服務到工做者：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工程。、