1. 什么是MVC模式

MVC模式誕生于上世紀(jì)七八十年代，至今仍存在于很多應(yīng)用之中，比如Java中的Struts、Spring MVC等架構(gòu)。這是一種經(jīng)典的設(shè)計(jì)模式，全名為Model-View-Controller，即模型-視圖-控制器。

(1) Model(模型)表示應(yīng)用程序核心，表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。

(2) View(視圖)顯示數(shù)據(jù)(數(shù)據(jù)庫(kù)記錄)，視圖是用戶(hù)看到并與之交互的界面。

(3) Controller(控制器)處理輸入(寫(xiě)入數(shù)據(jù)庫(kù)記錄)，控制器接受用戶(hù)的輸入并調(diào)用模型和視圖去完成用戶(hù)的需求，它只是接收請(qǐng)求并決定調(diào)用哪個(gè)模型構(gòu)件去處理請(qǐng)求，然后再確定用哪個(gè)視圖來(lái)顯示返回的數(shù)據(jù)。

使用MVC應(yīng)用程序被分為三個(gè)核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)，最典型的MVC就是JSP+servlet+javabean的模式。

2. MVC模式的優(yōu)點(diǎn)和缺點(diǎn)

MVC模式的誕生讓開(kāi)發(fā)更高效，讓代碼耦合度盡量減少，讓?xiě)?yīng)用更部分的職責(zé)更加清晰。

但是MVC框架也是有不足：

(1) 每次用戶(hù)的操作請(qǐng)求必須流程為：控制器-模型-視圖，用戶(hù)才能看到最終的界面;

(2) 視圖的呈現(xiàn)必須由模型來(lái)調(diào)研;

(3) 渲染視圖的過(guò)程在服務(wù)端來(lái)完成，最終呈現(xiàn)出來(lái)的是帶有模型的視圖頁(yè)面，性能無(wú)法得到很好的優(yōu)化。

為了使數(shù)據(jù)展現(xiàn)過(guò)程更加直接，并且提供更好的用戶(hù)體驗(yàn)，需要對(duì)MVC模式進(jìn)行改進(jìn)，首先從瀏覽器發(fā)送AJAX請(qǐng)求，然后服務(wù)端接受請(qǐng)求并返回JSON數(shù)據(jù)返回給瀏覽器，最后在瀏覽器端進(jìn)行渲染，如圖：

如果將瀏覽器一端視為前端，而服務(wù)器一端視為后端的話(huà)，如圖所示：

則經(jīng)過(guò)改進(jìn)后的模型，我們可以使用REST實(shí)現(xiàn)，前端關(guān)注界面展現(xiàn)，后端關(guān)注業(yè)務(wù)邏輯，分工明確，職責(zé)清晰。

3. 什么是REST

REST：REpresentational State

Transfer = 直接翻譯：表現(xiàn)層狀態(tài)轉(zhuǎn)移。這是一個(gè)”無(wú)狀態(tài)”的架構(gòu)模式，因?yàn)樵谌魏螘r(shí)候都可以由客戶(hù)端發(fā)出請(qǐng)求到服務(wù)端，最終返回自己想要的數(shù)據(jù)，當(dāng)前請(qǐng)求不會(huì)受到上次請(qǐng)求的影響。所以，REST也被人們看做是一種“輕量級(jí)”的SOA實(shí)現(xiàn)技術(shù)，因此在企業(yè)級(jí)應(yīng)用與互聯(lián)網(wǎng)應(yīng)用中都得到了廣泛應(yīng)用。

現(xiàn)在我們展示一個(gè)關(guān)于前后端分離的REST示例方便理解：

比如一個(gè)用戶(hù)訪(fǎng)問(wèn)餓了么的外賣(mài)網(wǎng)站，該網(wǎng)站對(duì)其所銷(xiāo)售的各個(gè)商家的店鋪或者商品進(jìn)行詳細(xì)分類(lèi)。當(dāng)用戶(hù)登陸該餓了么外賣(mài)平臺(tái)后，他首先需要在餓了么外賣(mài)平臺(tái)選擇其所需要尋找的商家或者商品分類(lèi)，進(jìn)而列出屬于該分類(lèi)的各個(gè)物品。

從業(yè)務(wù)邏輯的角度來(lái)說(shuō)這個(gè)流程很簡(jiǎn)單，但實(shí)際上瀏覽器向后臺(tái)發(fā)了多個(gè)請(qǐng)求：頁(yè)面邏輯加載時(shí)將首先得到所有的商品分類(lèi)，并將這些分類(lèi)顯示在頁(yè)面中。在用戶(hù)選擇了一個(gè)分類(lèi)的時(shí)候，頁(yè)面邏輯將發(fā)送一個(gè)請(qǐng)求得到該分類(lèi)的詳細(xì)信息，并發(fā)送一個(gè)請(qǐng)求來(lái)得到該分類(lèi)的列表，而服務(wù)器將返回所有的類(lèi)別。

二.前后端分離的好處是什么

如果沒(méi)有前后端分離，則隨著業(yè)務(wù)的拓展，前端代碼越來(lái)越復(fù)雜，如：

(1) 無(wú)法統(tǒng)一協(xié)作模式，代碼充滿(mǎn)了約定;

(2) JS跟CSS，依賴(lài)于厚度按產(chǎn)出的HTML;

(3) 有的數(shù)據(jù)來(lái)自AJXA，有的數(shù)據(jù)印在DOM上;

(4) 有的業(yè)務(wù)邏輯在前端，有的在model層，更多的是在view層。

其次前后端依舊高度耦合：

(1) 前端依賴(lài)服務(wù)端開(kāi)發(fā)環(huán)境;

(2) 在服務(wù)端View層高度耦合;

(3) 溝通成本很高;

(4) 職責(zé)不清晰。

還有無(wú)法良好的支持跨終端

(1) 業(yè)務(wù)邏輯散落在應(yīng)用中;

(2) 渲染邏輯強(qiáng)依賴(lài)后端頁(yè)面;

(3) 只能用responsive design硬來(lái)。

最終高度耦合的前后端分工：

(1) 溝通成本上升;

(2) 維護(hù)成本上升;

(3) 無(wú)法正確的快速響應(yīng)變化;

(4) 代碼的腐敗只是遲早的問(wèn)題。

而前后端分離之后：

(1) 后端只提供數(shù)據(jù)，處理業(yè)務(wù)邏輯，代碼跑在服務(wù)器上;

(2) 前端接收數(shù)據(jù)，返回?cái)?shù)據(jù)，處理渲染邏輯，代碼跑在瀏覽器上。

這樣分工明確。

三.什么情況下可以前后端分離

1. 頁(yè)面交互比較復(fù)雜;

2. 前端的渲染比較頻繁;

從以上的信息我們可以了解到：前后端的好處是可以提高辦理業(yè)務(wù)的效率的。前后端分離之后是為了分工可以更明確。想要了解更多前后端的信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。