1. 什么是MVC模式

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

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

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

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

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

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

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

但是MVC框架也是有不足：

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

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

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

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

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

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

3. 什么是REST

REST：REpresentational State

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

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

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

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

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

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

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

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

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

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

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

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

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

(3) 溝通成本很高;

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

還有無法良好的支持跨終端

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

(2) 渲染邏輯強(qiáng)依賴后端頁面;

(3) 只能用responsive design硬來。

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

(1) 溝通成本上升;

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

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

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

而前后端分離之后：

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

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

這樣分工明確。

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

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

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

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