Java中的WebMVC簡介_動力節(jié)點Java學(xué)院整理-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)公司2013年至今，先為湄潭等服務(wù)建站，湄潭等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為湄潭企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

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

1、Web瀏覽器（如IE）發(fā)起請求。

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

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

因此，在Web世界里：

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

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

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

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

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

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

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

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

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

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

那接下來我們看一下在Web里MVC是什么樣子，我們稱其為WebMVC來區(qū)別標(biāo)準(zhǔn)的MVC。

WebMVC概述

模型-視圖-控制器概念和標(biāo)準(zhǔn)MVC概念一樣，請參考1.2，我們再看一下WebMVC標(biāo)準(zhǔn)架構(gòu)，如圖1-3：

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

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

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

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

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

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

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

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

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

JSP本質(zhì)還是Servlet，最終在運行時會生成一個Servlet（如tomcat，將在tomcat\work\Catalina\web應(yīng)用名\org\apache\jsp下生成），但這種使得寫html簡單點，但仍是控制邏輯、表現(xiàn)代碼、業(yè)務(wù)邏輯對象調(diào)用混雜在一起。

Model1：可以認(rèn)為是JSP的增強版，可以認(rèn)為是jsp+javabean如圖1-7

特點：使用jsp:useBean標(biāo)準(zhǔn)動作，自動將請求參數(shù)封裝為JavaBean組件；還必須使用java腳本執(zhí)行控制邏輯。

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

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

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

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

具體代碼事例如下：

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

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

控制器：

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

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

4.選擇下一個視圖，嚴(yán)重依賴ServletAPI，這樣很難或基本不可能更換視圖；

5.給視圖傳輸要展示的模型數(shù)據(jù)，使用ServletAPI，更換視圖技術(shù)也要一起更換，很麻煩。

1模型：

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

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

服務(wù)到工作者：FrontController+ApplicationController+PageController+Context

即，前端控制器+應(yīng)用控制器+頁面控制器（也有稱其為動作）+上下文，也是WebMVC，只是責(zé)任更加明確如圖1-10：

運行流程如下：

職責(zé)：

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

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

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

Context：上下文，還記得Model2中為視圖準(zhǔn)備要展示的模型數(shù)據(jù)嗎，我們直接放在request中（ServletAPI相關(guān)），有了上下文之后，我們就可以將相關(guān)數(shù)據(jù)放置在上下文，從而與協(xié)議無關(guān)（如ServletAPI）的訪問/設(shè)置模型數(shù)據(jù)，一般通過ThreadLocal模式實現(xiàn)。

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

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

模型和視圖的分離；

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

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

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

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

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

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

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

文章題目：Java中的WebMVC簡介_動力節(jié)點Java學(xué)院整理-創(chuàng)新互聯(lián)
鏈接地址：http://muchs.cn/article26/hiscg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、軟件開發(fā)、ChatGPT、小程序開發(fā)、響應(yīng)式網(wǎng)站、網(wǎng)頁設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)