Web MVC簡(jiǎn)介

1.1、Web開發(fā)中的要求-響應(yīng)模型：

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

1、  Web閱讀器（如IE）發(fā)起要求，如訪問http://sishuok.com

2、  Web服務(wù)器（如Tomcat）接收要求，處理要求（比如用戶新增，則將把用戶保存1下），最后產(chǎn)生響應(yīng)（1般為html）。

3、web服務(wù)器處理完成后，返回內(nèi)容給web客戶端（1般就是我們的閱讀器），客戶端對(duì)接收的內(nèi)容進(jìn)行處理（如web閱讀器將會(huì)對(duì)接收到的html內(nèi)容進(jìn)行渲染以展現(xiàn)給客戶）。

因此，在Web世界里：

都是Web客戶端發(fā)起要求，Web服務(wù)器接收、處理并產(chǎn)生響應(yīng)。

1般Web服務(wù)器是不能主動(dòng)通知Web客戶端更新內(nèi)容。雖然現(xiàn)在有些技術(shù)如服務(wù)器推（如Comet）、還有現(xiàn)在的HTML5 websocket可以實(shí)現(xiàn)Web服務(wù)器主動(dòng)通知Web客戶端。

到此我們了解了在web開發(fā)時(shí)的要求/響應(yīng)模型，接下來我們看1下標(biāo)準(zhǔn)的MVC模型是甚么。

1.2、標(biāo)準(zhǔn)MVC模型概述

MVC模型：是1種架構(gòu)型的模式，本身不引入新功能，只是幫助我們將開發(fā)的結(jié)構(gòu)組織的更加公道，使展現(xiàn)與模型分離、流程控制邏輯、業(yè)務(wù)邏輯調(diào)用與展現(xiàn)邏輯分離。如圖1⑵

圖1⑵

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

Model（模型）：數(shù)據(jù)模型，提供要展現(xiàn)的數(shù)據(jù)，因此包括數(shù)據(jù)和行動(dòng)，可以認(rèn)為是領(lǐng)域模型或JavaBean組件（包括數(shù)據(jù)和行動(dòng)），不過現(xiàn)在1般都分離開來：Value Object（數(shù)據(jù)） 和 服務(wù)層（行動(dòng)）。也就是模型提供了模型數(shù)據(jù)查詢和模型數(shù)據(jù)的狀態(tài)更新等功能，包括數(shù)據(jù)和業(yè)務(wù)。

View（視圖）：負(fù)責(zé)進(jìn)行模型的展現(xiàn)，1般就是我們見到的用戶界面，客戶想看到的東西。

Controller（控制器）：接收用戶要求，拜托給模型進(jìn)行處理（狀態(tài)改變），處理終了后把返回的模型數(shù)據(jù)返回給視圖，由視圖負(fù)責(zé)展現(xiàn)。 也就是說控制器做了個(gè)調(diào)度員的工作，。

從圖1⑴我們還看到，在標(biāo)準(zhǔn)的MVC中模型能主動(dòng)推數(shù)據(jù)給視圖進(jìn)行更新（視察者設(shè)計(jì)模式，在模型上注冊(cè)視圖，當(dāng)模型更新時(shí)自動(dòng)更新視圖），但在Web開發(fā)中模型是沒法主動(dòng)推給視圖（沒法主動(dòng)更新用戶界面），由于在Web開發(fā)是要求-響應(yīng)模型。

那接下來我們看1下在Web里MVC是甚么模樣，我們稱其為 Web MVC 來區(qū)分標(biāo)準(zhǔn)的MVC。

1.3、Web MVC概述

模型-視圖-控制器概念和標(biāo)準(zhǔn)MVC概念1樣，請(qǐng)參考1.2，我們?cè)倏?下Web MVC標(biāo)準(zhǔn)架構(gòu)，如圖1⑶：

如圖1⑶

在Web MVC模式下，模型沒法主動(dòng)推數(shù)據(jù)給視圖，如果用戶想要視圖更新，需要再發(fā)送1次要求（即要求-響應(yīng)模型）。

概念差不多了，我們接下來了解下Web端開發(fā)的發(fā)展歷程，和使用代碼來演示1下Web MVC是如何實(shí)現(xiàn)的，還有為何要使用MVC這個(gè)模式呢？

1.4、Web端開發(fā)發(fā)展歷程

此處我們只是簡(jiǎn)單的敘述比較核心的歷程，如圖1⑷

圖1⑷

1.4.1、CGI：（Common Gateway Interface）公共網(wǎng)關(guān)接口，1種在web服務(wù)端使用的腳本技術(shù)，使用C或Perl語言編寫，用于接收web用戶要求并處理，最后動(dòng)態(tài)產(chǎn)生響應(yīng)給用戶，但每次要求將產(chǎn)生1個(gè)進(jìn)程，重量級(jí)。

1.4.2、Servlet：1種JavaEE web組件技術(shù)，是1種在服務(wù)器端履行的web組件，用于接收web用戶要求并處理，最后動(dòng)態(tài)產(chǎn)生響應(yīng)給用戶。但每次要求只產(chǎn)生1個(gè)線程（而且有線程池），輕量級(jí)。而且能利用許多JavaEE技術(shù)（如JDBC等）。本質(zhì)就是在java代碼里面 輸出 html流。但表現(xiàn)邏輯、控制邏輯、業(yè)務(wù)邏輯調(diào)用混雜。如圖1⑸    

圖1⑸

如圖1⑸，這類做法是絕對(duì)不可取的，控制邏輯、表現(xiàn)代碼、業(yè)務(wù)邏輯對(duì)象調(diào)用混雜在1起，最大的問題是直接在Java代碼里面輸出Html，這樣前端開發(fā)人員沒法進(jìn)行頁面風(fēng)格等的設(shè)計(jì)與修改，即便修改也是很麻煩，因此實(shí)際項(xiàng)目這類做法不可取。

1.4.3、JSP：（Java Server Page）：1種在服務(wù)器端履行的web組件，是1種運(yùn)行在標(biāo)準(zhǔn)的HTML頁面中嵌入腳本語言（現(xiàn)在只支持Java）的模板頁面技術(shù)。本質(zhì)就是在html代碼中嵌入java代碼。JSP終究還是會(huì)被編譯為Servlet，只不過比純Servlet開發(fā)頁面更簡(jiǎn)單、方便。但表現(xiàn)邏輯、控制邏輯、業(yè)務(wù)邏輯調(diào)用還是混雜。如圖1⑹

圖1⑹

如圖1⑹，這類做法也是絕對(duì)不可取的，控制邏輯、表現(xiàn)代碼、業(yè)務(wù)邏輯對(duì)象調(diào)用混雜在1起，但比直接在servlet里輸出html要好1點(diǎn)，前端開發(fā)人員可以進(jìn)行簡(jiǎn)單的頁面風(fēng)格等的設(shè)計(jì)與修改（但如果嵌入的java腳本太多也是很難修改的），因此實(shí)際項(xiàng)目這類做法不可取。

JSP本質(zhì)還是Servlet，終究在運(yùn)行時(shí)會(huì)生成1個(gè)Servlet（如tomcat，將在tomcat\work\Catalina\web利用名\org\apache\jsp下生成），但這類使得寫html簡(jiǎn)單點(diǎn)，但還是控制邏輯、表現(xiàn)代碼、業(yè)務(wù)邏輯對(duì)象調(diào)用混雜在1起。

1.4.4、Model1：可以認(rèn)為是JSP的增強(qiáng)版，可以認(rèn)為是jsp+javabean如圖1⑺

特點(diǎn)：使用<jsp:useBean>標(biāo)準(zhǔn)動(dòng)作，自動(dòng)將要求參數(shù)封裝為JavaBean組件；還必須使用java腳本履行控制邏輯。

圖1⑺

此處我們可以看出，使用<jsp:useBean>標(biāo)準(zhǔn)動(dòng)作可以簡(jiǎn)化javabean的獲得/創(chuàng)建，及將要求參數(shù)封裝到j(luò)avabean，再看1下Model1架構(gòu)，如圖1⑻。

圖1⑻ Model1架構(gòu)

Model1架構(gòu)中，JSP負(fù)責(zé)控制邏輯、表現(xiàn)邏輯、業(yè)務(wù)對(duì)象（javabean）的調(diào)用，只是比純JSP簡(jiǎn)化了獲得要求參數(shù)和封裝要求參數(shù)。一樣是不好的，在項(xiàng)目中應(yīng)當(dāng)嚴(yán)禁使用（或最多再demo里使用）。

1.4.5、Model2：在JavaEE世界里，它可以認(rèn)為就是Web MVC模型

Model2架構(gòu)其實(shí)可以認(rèn)為就是我們所說的Web MVC模型，只是控制器采取Servlet、模型采取JavaBean、視圖采取JSP，如圖1⑼

圖1⑼ Model2架構(gòu)

具體代碼事例以下：

從Model2架構(gòu)可以看出，視圖和模型分離了，控制邏輯和展現(xiàn)邏輯分離了。

但我們也看到嚴(yán)重的缺點(diǎn)：

1．  1、控制器：

1．1．1、控制邏輯可能比較復(fù)雜，其實(shí)我們可以依照規(guī)約，如要求參數(shù)submitFlag=toAdd，我們其實(shí)可以直接調(diào)用toAdd方法，來簡(jiǎn)化控制邏輯；而且每一個(gè)模塊基本需要1個(gè)控制器，造成控制邏輯可能很復(fù)雜；

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

1．1．3、選擇下1個(gè)視圖，嚴(yán)重依賴Servlet API，這樣很難或基本不可能更換視圖；

1．1．4、給視圖傳輸要展現(xiàn)的模型數(shù)據(jù)，使用Servlet API，更換視圖技術(shù)也要1起更換，很麻煩。

1.2、模型：

1．2．1、此處模型使用JavaBean，可能造成JavaBean組件類很龐大，1般現(xiàn)在項(xiàng)目都是采取3層架構(gòu)，而不采取JavaBean。

1.3、視圖

1．3．1、現(xiàn)在被綁定在JSP，很難更換視圖，比如Velocity、FreeMarker；比如我要支持Excel、PDF視圖等等。

1.4.5、服務(wù)到工作者：Front Controller + Application Controller + Page Controller + Context

即，前端控制器+利用控制器+頁面控制器（也有稱其為動(dòng)作）+上下文，也是Web MVC，只是責(zé)任更加明確，詳情請(qǐng)參考《核心J2EE設(shè)計(jì)模式》和《企業(yè)利用架構(gòu)模式》如圖1⑴0：

圖1⑴0

運(yùn)行流程以下：

職責(zé)：

Front Controller：前端控制器，負(fù)責(zé)為表現(xiàn)層提供統(tǒng)1訪問點(diǎn)，從而避免Model2中出現(xiàn)的重復(fù)的控制邏輯（由前端控制器統(tǒng)1回調(diào)相應(yīng)的功能方法，如前邊的根據(jù)submitFlag=login轉(zhuǎn)調(diào)login方法）；并且可以為多個(gè)要求提供共用的邏輯（如準(zhǔn)備上下文等等），將選擇具體視圖和具體的功能處理（如login里邊封裝要求參數(shù)到模型，并調(diào)用業(yè)務(wù)邏輯對(duì)象）分離。

Application Controller：利用控制器，前端控制器分離選擇具體視圖和具體的功能處理以后，需要有人來管理，利用控制器就是用來選擇具體視圖技術(shù)（視圖的管理）和具體的功能處理（頁面控制器/命令對(duì)象/動(dòng)作管理），1種策略設(shè)計(jì)模式的利用，可以很容易的切換視圖/頁面控制器，相互不產(chǎn)生影響。

Page Controller(Command)：頁面控制器/動(dòng)作/處理器：功能處理代碼，搜集參數(shù)、封裝參數(shù)到模型，轉(zhuǎn)調(diào)業(yè)務(wù)對(duì)象處理模型，返回邏輯視圖名交給前端控制器（和具體的視圖技術(shù)解耦），由前端控制器拜托給利用控制器選擇具體的視圖來展現(xiàn)，可以是命令設(shè)計(jì)模式的實(shí)現(xiàn)。頁面控制器也被稱為處理器或動(dòng)作。

Context：上下文，還記得Model2中為視圖準(zhǔn)備要展現(xiàn)的模型數(shù)據(jù)嗎，我們直接放在request中（Servlet API相干），有了上下文以后，我們就能夠?qū)⑾喔蓴?shù)據(jù)放置在上下文，從而與協(xié)議無關(guān)（如Servlet API）的訪問/設(shè)置模型數(shù)據(jù)，1般通過ThreadLocal模式實(shí)現(xiàn)。

到此，我們回顧了全部web開發(fā)架構(gòu)的發(fā)展歷程，可能不同的web層框架在細(xì)節(jié)處理方面不同，但的目的是1樣的：

干凈的web表現(xiàn)層：

    模型和視圖的分離；

控制器中的控制邏輯與功能處理分離（搜集并封裝參數(shù)到模型對(duì)象、業(yè)務(wù)對(duì)象調(diào)用）；

控制器中的視圖選擇與具體視圖技術(shù)分離。

輕浮的web表現(xiàn)層：

    做的事情越少越好，薄薄的，不應(yīng)當(dāng)包括無關(guān)代碼；

       只負(fù)責(zé)搜集并組織參數(shù)到模型對(duì)象，啟動(dòng)業(yè)務(wù)對(duì)象的調(diào)用；

       控制器只返回邏輯視圖名并由相應(yīng)的利用控制器來選擇具體使用的視圖策略；

       盡可能少使用框架特定API，保證容易測(cè)試。

到此我們了解Web MVC的發(fā)展歷程，接下來讓我們了解下Spring MVC究竟是甚么、架構(gòu)及來個(gè)HelloWorld了解下具體怎樣使用吧。