你真的理解了MVC, MVP, MVVM嗎？
前言： 準備寫這篇文章的時候 ， 我自認為對MVC已經有深刻理解了，可是畫圖的時候發現，理解還是有漏洞，于是又閱讀，思考，整理，加深了理解， 寫了這篇文章， 估計還有漏洞，歡迎討論。
這再一次說明了寫作的好處： 很多時候自以為理解了，實際上腦海中有很多想當然的假設，寫作會把這些假設給暴露出來。
大概是二三十年前， 人類逐漸從命令行界面時代走出來，進化到了GUI時代。
注： GUI（Graphic User Interface），即圖形用戶接口。
（一個命令行程序）
（一個帶有圖形界面的桌面應用程序 ，自己畫的，有點丑?。?/p>
每當人類努力地開發新的桌面GUI程序的時候， 至少要搞定下面幾類工作：
1. 界面（以及界面中元素的）布局。
這是一件挺費勁的工作， 要盡可能地美觀漂亮，要不然就賣不出去。
2. 界面上有些“邏輯”需要處理
比如上圖中那個薪水計算程序，“計算” 按鈕默認是灰色的， 不能點擊，用戶輸入了稅前收入以后， “計算”按鈕就會被激活，表示計算了。
3. 所謂的業務邏輯。
用戶點擊了“計算”按鈕以后，計算五險一金，個人所得稅和稅后收入。
這三者攪在一起，讓程序代碼凌亂不堪，稍微復雜點兒的程序就長達幾千行， 不斷地挑戰著程序員的底線，修改別人的代碼，添加新的功能要比從頭寫難好多倍！
大家都在泥潭中掙扎。
桌面應用程序的 MVC
程序越來越復雜，Bug越來越多，沒辦法， 大家只好去求編程上帝。
上帝說： 想從困境中走出來，一定要實現關注點分離（Separation of concerns）。
沒人能夠理解。
上帝解釋道：“ 你們人腦同時能處理的東西是有限的， 所以要把一個大系統給分解，變成幾個相對獨立的部分，這樣我們的大腦每次只關注某一方面，暫時忽略其他的，就能夠掌控了。”
沒人知道該怎么分解。
上帝只好想了一個辦法， 把關注點分離的理論給具體化，這個辦法就是MVC。
上帝告訴人類：
M 表示 Model , 專門用來處理業務邏輯，不干別的事情。
例如在那個薪水計算系統中。計算一個人的薪水，五險一金，個人所得稅等等。
V 表示View， 專注頁面布局和數據顯示。
例如把Button放置到某個位置，把總收入顯示到一個文本框，把稅金顯示到另外一個地方。
C 表示Controller 翻譯用戶的輸入，操作模型和視圖。
例如，用戶在界面點擊了一個“計算”的按鈕，View 把計算的請求傳遞給Controller (很明顯View需要知道Controller，換句話說，需要持有Controller的實例)，Controller找到或者創建Model，執行業務邏輯：計算薪水。
計算的結果該怎么展示呢？ 人類問道。
上帝胸有成竹： 可以讓Model 去通知View。
Model需要持有View的實例（當然也可以通過觀察者模式），調用View對應的方法。
例如： View中可能有一個onResult的方法， 讓Model去調用，在調用的時候把一個參數對象Salary傳遞過來，不就可以展示數據了嗎？
- // View的方法，被Model調用：
- public void onResult(Salary salary){
- //把個人所得稅(salary.getTax()) 展示到一個文本框
- //把凈收入(salary.getNetPay()) 展示到另外一個文本框
- ......
- }
畫成流程圖的話是這個樣子：
大家都覺得MVC大法好，紛紛開始使用。
MVP
時間久了以后，人類就覺得不爽了，因為在這個MVC中，依賴太多：
View 依賴Controller和Model
Controller依賴View和Model
Model 和View的關系雖然很弱， 但是也需要某種方式來通知View進行數據更新。
人類說：“他們之間的耦合還是挺緊密的啊，親愛的上帝，能不能改改？”
上帝覺的人類還是挺有上進心的，決定繼續施以援手： “這樣吧， 可以改變一下Controller， 把Model和View完全隔離開，讓他們單獨變化。”
上帝把Controller 改了個名稱，叫做Presenter， 把整體命名為MVP。
在MVP當中，View只知道Presenter, 不知道Model 。
計算流程和MVC差不多，用戶點擊了“計算薪水”按鈕， View去調用Presenter， Presenter操作Model , Model 中進行業務計算。 關鍵點是，Presenter去更新View。
- //Presenter 的方法，被View調用
- public void calculateSalary(){
- //調用Model計算薪水
- view.showTax(xxx); // 調用View顯示所得稅
- view.showNetPay(xxxx);// 調用View凈收入
- ......
- }
但是Presenter還是需要調用View的方法，也就是說Presenter對View有依賴，這樣Presenter就沒辦法單獨做單元測試，非得等到界面做好以后才行。
于是上帝又做了一點改進，讓View層提取出接口，Presenter只依賴這個接口。
這樣Presenter不用依賴真正的界面就可以測試了，并且也增加了復用性，只要View實現了那個接口，Presenter就可以大發神威。
MVVM
使用了一段時間MVP以后，永不滿足的人類又覺得不爽了， 因為讓Presenter調用View的方法去設置界面，仍然需要大量的、煩人的代碼，這實在是一件不舒服的事情。
人類突發奇想： 能不能告訴View一個數據結構，然后View就能根據這個數據結構的變化而自動隨之變化呢？
上帝看到人類思考了，表示了贊賞。
他說，我來送你們一個叫做ViewModel的東西，它可以和View層綁定。 ViewModel的變化，View立刻就會變化。
人類問： ViewModel？ 里邊有什么東西？
上帝說： 拿你們的薪水計算為例， ViewModel 差不多這樣：
- public class SalaryViewModel{
- String grossSalary; //稅前收入，和View中的相關字段對應
- String netSalary; //凈收入，和View中的相關字段對應
- String tax; //個人所得稅，和View中的相關字段對應
- ......
- boolean isCalculating; // 一個標志位，表示正在計算
- String errMsg; // 如果出錯的話，記錄出錯消息。
- }
當用戶在界面上點擊“計算”按鈕的時候， 你們需要設置一個SalaryViewModel中的標志位：
salaryViewModel.isCalculating = true;
這樣View 中就可以自動給用戶展示一個消息：“正在計算....”
當薪水計算完成的時候， 如果沒有錯誤，SalaryViewModel 中grossSalary， netSalary，tax等屬性就有了值。 與此同時View 中對應的內容也會更新， 不用你們手工去設置， 很方便吧？
如果計算過程出錯， SalaryViewModel 的errMsg 會保存出錯消息， 同樣，View中會自動把這個錯誤消息給顯示出來， 很智能吧？
人類說：“怎么可能這么智能呢？ 這里的ViewModel 好像和View沒有什么關系??？ 到底該怎么綁定??？?。?！”
上帝笑了： 你們可以開發一個框架嘛？ 讓兩者綁定起來不就行了？
人類沒有辦法，只好自己動手。
（注：實際上微軟的WPF和Silverlight， Android等框架和系統都可以實現View和ViewModel之間的映射和綁定）
Web應用程序的MVC
時間過得飛快，人類發明了互聯網，Web應用程序如雨后春筍般崛起，B/S(瀏覽器-服務器)開始大行其道。
用戶通過瀏覽器發出GET,POST請求，服務器端進行處理，處理完以后生成HTML給瀏覽器。
無論什么操作，都是對服務器端URL的訪問。
人類突然發現，整個編程模型發生了巨變， 不能簡單地套用原來的MVC和MVP了。
如果把HTML頁面比作原來桌面應用程序的View， 服務器無論是Controller還是Model都是無法遠程遙控這個View進行處理的。
人類這一次沒有去請教上帝，自己嘗試對MVC進行改良，其中有個叫Rod Johnson 帶領一幫人搞出的SpringMVC很成功。
不像桌面應用的MVC， 這里的Model沒法給View 發通知。
也不像MVP, 這里的Controller 也不會調用View的方法來設置界面。
實際上Controller 會選擇一個View， 然后把模型數據“丟過去”渲染。
原來的View 變成了 View Template（例如JSP , Velocity等等）， 經過渲染后變成HTML發給瀏覽器展示給用戶。
有人把這種MVC稱為 基于Web的 MVC，以便和之前的MVC區別開來。
前后端的分離
人類早期的B/S應用程序中， 每次訪問服務器端， HTML就會整體發給瀏覽器，即所謂的整體刷新。
后來人類發明了AJAX， 可以做到局部刷新。
于是瀏覽器端的應用變得越來越復雜，再后來人類竟然發明了Web上的SPA(單頁應用程序)，用起來的體驗和最初的桌面應用程序越來越像。
人類發現，那些MVC, MVVM之類的模式完全可以用到瀏覽器端嘛！
例如在瀏覽器端使用MVVM , 在服務器端可以使用MVC， 兩者結合起來：
前端和后端成功地分家了 ！
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
