前言： 準(zhǔn)備寫這篇文章的時(shí)候 ， 我自認(rèn)為對(duì)MVC已經(jīng)有深刻理解了，可是畫圖的時(shí)候發(fā)現(xiàn)，理解還是有漏洞，于是又閱讀，思考，整理，加深了理解， 寫了這篇文章， 估計(jì)還有漏洞，歡迎討論。

這再一次說明了寫作的好處： 很多時(shí)候自以為理解了，實(shí)際上腦海中有很多想當(dāng)然的假設(shè)，寫作會(huì)把這些假設(shè)給暴露出來。

大概是二三十年前， 人類逐漸從命令行界面時(shí)代走出來，進(jìn)化到了GUI時(shí)代。

注： GUI（Graphic User Interface），即圖形用戶接口。

（一個(gè)命令行程序）

（一個(gè)帶有圖形界面的桌面應(yīng)用程序 ，自己畫的，有點(diǎn)丑?。?/p>

每當(dāng)人類努力地開發(fā)新的桌面GUI程序的時(shí)候， 至少要搞定下面幾類工作：

1. 界面（以及界面中元素的）布局。

這是一件挺費(fèi)勁的工作， 要盡可能地美觀漂亮，要不然就賣不出去。

2. 界面上有些“邏輯”需要處理

比如上圖中那個(gè)薪水計(jì)算程序，“計(jì)算” 按鈕默認(rèn)是灰色的， 不能點(diǎn)擊，用戶輸入了稅前收入以后， “計(jì)算”按鈕就會(huì)被激活，表示計(jì)算了。

3. 所謂的業(yè)務(wù)邏輯。

用戶點(diǎn)擊了“計(jì)算”按鈕以后，計(jì)算五險(xiǎn)一金，個(gè)人所得稅和稅后收入。

這三者攪在一起，讓程序代碼凌亂不堪，稍微復(fù)雜點(diǎn)兒的程序就長(zhǎng)達(dá)幾千行， 不斷地挑戰(zhàn)著程序員的底線，修改別人的代碼，添加新的功能要比從頭寫難好多倍！

大家都在泥潭中掙扎。

桌面應(yīng)用程序的 MVC

程序越來越復(fù)雜，Bug越來越多，沒辦法， 大家只好去求編程上帝。

上帝說： 想從困境中走出來，一定要實(shí)現(xiàn)關(guān)注點(diǎn)分離（Separation of concerns）。

沒人能夠理解。

上帝解釋道：“ 你們?nèi)四X同時(shí)能處理的東西是有限的， 所以要把一個(gè)大系統(tǒng)給分解，變成幾個(gè)相對(duì)獨(dú)立的部分，這樣我們的大腦每次只關(guān)注某一方面，暫時(shí)忽略其他的，就能夠掌控了。”

沒人知道該怎么分解。

上帝只好想了一個(gè)辦法， 把關(guān)注點(diǎn)分離的理論給具體化，這個(gè)辦法就是MVC。

上帝告訴人類：

M 表示 Model , 專門用來處理業(yè)務(wù)邏輯，不干別的事情。

例如在那個(gè)薪水計(jì)算系統(tǒng)中。計(jì)算一個(gè)人的薪水，五險(xiǎn)一金，個(gè)人所得稅等等。

V 表示View， 專注頁(yè)面布局和數(shù)據(jù)顯示。

例如把Button放置到某個(gè)位置，把總收入顯示到一個(gè)文本框，把稅金顯示到另外一個(gè)地方。

C 表示Controller  翻譯用戶的輸入，操作模型和視圖。

例如，用戶在界面點(diǎn)擊了一個(gè)“計(jì)算”的按鈕，View 把計(jì)算的請(qǐng)求傳遞給Controller (很明顯View需要知道Controller，換句話說，需要持有Controller的實(shí)例)，Controller找到或者創(chuàng)建Model，執(zhí)行業(yè)務(wù)邏輯：計(jì)算薪水。

計(jì)算的結(jié)果該怎么展示呢？  人類問道。

上帝胸有成竹： 可以讓Model 去通知View。

Model需要持有View的實(shí)例（當(dāng)然也可以通過觀察者模式），調(diào)用View對(duì)應(yīng)的方法。

例如： View中可能有一個(gè)onResult的方法， 讓Model去調(diào)用，在調(diào)用的時(shí)候把一個(gè)參數(shù)對(duì)象Salary傳遞過來，不就可以展示數(shù)據(jù)了嗎？

// View的方法，被Model調(diào)用：  
public void onResult(Salary salary){    
      //把個(gè)人所得稅(salary.getTax()) 展示到一個(gè)文本框 
      //把凈收入(salary.getNetPay()) 展示到另外一個(gè)文本框 
      ...... 
} 

畫成流程圖的話是這個(gè)樣子：

大家都覺得MVC大法好，紛紛開始使用。

MVP

時(shí)間久了以后，人類就覺得不爽了，因?yàn)樵谶@個(gè)MVC中，依賴太多：

View 依賴Controller和Model

Controller依賴View和Model

Model 和View的關(guān)系雖然很弱， 但是也需要某種方式來通知View進(jìn)行數(shù)據(jù)更新。

人類說：“他們之間的耦合還是挺緊密的啊，親愛的上帝，能不能改改？”

上帝覺的人類還是挺有上進(jìn)心的，決定繼續(xù)施以援手： “這樣吧， 可以改變一下Controller， 把Model和View完全隔離開，讓他們單獨(dú)變化。”

上帝把Controller 改了個(gè)名稱，叫做Presenter， 把整體命名為MVP。

在MVP當(dāng)中，View只知道Presenter, 不知道Model 。

計(jì)算流程和MVC差不多，用戶點(diǎn)擊了“計(jì)算薪水”按鈕， View去調(diào)用Presenter， Presenter操作Model , Model 中進(jìn)行業(yè)務(wù)計(jì)算。 關(guān)鍵點(diǎn)是，Presenter去更新View。

//Presenter 的方法，被View調(diào)用 
public void calculateSalary(){ 
    //調(diào)用Model計(jì)算薪水 
    view.showTax(xxx);    // 調(diào)用View顯示所得稅 
    view.showNetPay(xxxx);//  調(diào)用View凈收入 
    ...... 
} 

但是Presenter還是需要調(diào)用View的方法，也就是說Presenter對(duì)View有依賴，這樣Presenter就沒辦法單獨(dú)做單元測(cè)試，非得等到界面做好以后才行。

于是上帝又做了一點(diǎn)改進(jìn)，讓View層提取出接口，Presenter只依賴這個(gè)接口。

這樣Presenter不用依賴真正的界面就可以測(cè)試了，并且也增加了復(fù)用性，只要View實(shí)現(xiàn)了那個(gè)接口，Presenter就可以大發(fā)神威。

MVVM

使用了一段時(shí)間MVP以后，永不滿足的人類又覺得不爽了， 因?yàn)樽孭resenter調(diào)用View的方法去設(shè)置界面，仍然需要大量的、煩人的代碼，這實(shí)在是一件不舒服的事情。

人類突發(fā)奇想： 能不能告訴View一個(gè)數(shù)據(jù)結(jié)構(gòu)，然后View就能根據(jù)這個(gè)數(shù)據(jù)結(jié)構(gòu)的變化而自動(dòng)隨之變化呢？

上帝看到人類思考了，表示了贊賞。

他說，我來送你們一個(gè)叫做ViewModel的東西，它可以和View層綁定。 ViewModel的變化，View立刻就會(huì)變化。

人類問： ViewModel？ 里邊有什么東西？

上帝說： 拿你們的薪水計(jì)算為例， ViewModel 差不多這樣：

public class SalaryViewModel{ 
    String grossSalary;  //稅前收入，和View中的相關(guān)字段對(duì)應(yīng) 
    String netSalary;    //凈收入，和View中的相關(guān)字段對(duì)應(yīng) 
    String tax;          //個(gè)人所得稅，和View中的相關(guān)字段對(duì)應(yīng) 
    ......  
    boolean  isCalculating;  // 一個(gè)標(biāo)志位，表示正在計(jì)算  
    String errMsg;           // 如果出錯(cuò)的話，記錄出錯(cuò)消息。 
} 

當(dāng)用戶在界面上點(diǎn)擊“計(jì)算”按鈕的時(shí)候， 你們需要設(shè)置一個(gè)SalaryViewModel中的標(biāo)志位：

salaryViewModel.isCalculating = true;

這樣View 中就可以自動(dòng)給用戶展示一個(gè)消息：“正在計(jì)算....”

當(dāng)薪水計(jì)算完成的時(shí)候， 如果沒有錯(cuò)誤，SalaryViewModel 中g(shù)rossSalary， netSalary，tax等屬性就有了值。 與此同時(shí)View 中對(duì)應(yīng)的內(nèi)容也會(huì)更新， 不用你們手工去設(shè)置， 很方便吧？

如果計(jì)算過程出錯(cuò)， SalaryViewModel 的errMsg 會(huì)保存出錯(cuò)消息， 同樣，View中會(huì)自動(dòng)把這個(gè)錯(cuò)誤消息給顯示出來， 很智能吧？

人類說：“怎么可能這么智能呢？ 這里的ViewModel 好像和View沒有什么關(guān)系?。?到底該怎么綁定?。浚。?！”

上帝笑了： 你們可以開發(fā)一個(gè)框架嘛？ 讓兩者綁定起來不就行了？

人類沒有辦法，只好自己動(dòng)手。

（注：實(shí)際上微軟的WPF和Silverlight，  Android等框架和系統(tǒng)都可以實(shí)現(xiàn)View和ViewModel之間的映射和綁定）

Web應(yīng)用程序的MVC

時(shí)間過得飛快，人類發(fā)明了互聯(lián)網(wǎng)，Web應(yīng)用程序如雨后春筍般崛起，B/S(瀏覽器-服務(wù)器)開始大行其道。

用戶通過瀏覽器發(fā)出GET,POST請(qǐng)求，服務(wù)器端進(jìn)行處理，處理完以后生成HTML給瀏覽器。

無(wú)論什么操作，都是對(duì)服務(wù)器端URL的訪問。

人類突然發(fā)現(xiàn)，整個(gè)編程模型發(fā)生了巨變， 不能簡(jiǎn)單地套用原來的MVC和MVP了。

如果把HTML頁(yè)面比作原來桌面應(yīng)用程序的View， 服務(wù)器無(wú)論是Controller還是Model都是無(wú)法遠(yuǎn)程遙控這個(gè)View進(jìn)行處理的。

人類這一次沒有去請(qǐng)教上帝，自己嘗試對(duì)MVC進(jìn)行改良，其中有個(gè)叫Rod Johnson 帶領(lǐng)一幫人搞出的SpringMVC很成功。

不像桌面應(yīng)用的MVC， 這里的Model沒法給View 發(fā)通知。

也不像MVP, 這里的Controller 也不會(huì)調(diào)用View的方法來設(shè)置界面。

實(shí)際上Controller 會(huì)選擇一個(gè)View， 然后把模型數(shù)據(jù)“丟過去”渲染。

原來的View 變成了 View Template（例如JSP , Velocity等等）， 經(jīng)過渲染后變成HTML發(fā)給瀏覽器展示給用戶。

有人把這種MVC稱為 基于Web的 MVC，以便和之前的MVC區(qū)別開來。

前后端的分離

人類早期的B/S應(yīng)用程序中， 每次訪問服務(wù)器端， HTML就會(huì)整體發(fā)給瀏覽器，即所謂的整體刷新。

后來人類發(fā)明了AJAX， 可以做到局部刷新。

于是瀏覽器端的應(yīng)用變得越來越復(fù)雜，再后來人類竟然發(fā)明了Web上的SPA(單頁(yè)應(yīng)用程序)，用起來的體驗(yàn)和最初的桌面應(yīng)用程序越來越像。

人類發(fā)現(xiàn)，那些MVC, MVVM之類的模式完全可以用到瀏覽器端嘛！

例如在瀏覽器端使用MVVM , 在服務(wù)器端可以使用MVC， 兩者結(jié)合起來：

前端和后端成功地分家了 ！

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)coderising獲取授權(quán)】

戳這里，看該作者更多好文