摘要：，的事件回調(diào)函數(shù)中調(diào)用的操作方法。以為例調(diào)用關(guān)系模式實際就是將中的改名為，調(diào)用過程基本一致，最大的改良是間的雙向綁定。和間，有一個對象，可以操作修改，使用。

參考：
MVC，MVP 和 MVVM 的圖示 - 阮一峰
http://www.ruanyifeng.com/blo...
Web開發(fā)的MVVM模式
http://www.cnblogs.com/dxy198...
界面之下：還原真實的MV*模式
https://segmentfault.com/a/11...
Angular沉思錄（一）數(shù)據(jù)綁定
https://github.com/xufei/blog...
深入理解JavaScript系列（32）：設(shè)計模式之觀察者模式
http://www.cnblogs.com/TomXu/...

MVC/MVP/MVVM 在很多博問中都有整理，這里我根據(jù)閱讀博文和自己的理解，梳理一下 web 前端 html、css、javascript 中的他們。

用戶行為輸入，View 傳遞給 Controller（在JS中通過事件監(jiān)聽實現(xiàn)）；Controller 進行應(yīng)用邏輯處理，調(diào)用 Model 暴露的接口方法操作 Model；View 與 Model 間為觀察者模式，Model 更新完數(shù)據(jù)后通知 View 更新。
JS中的觀察者模式 - 湯姆大叔博文，本文闡述了如何在JS中實現(xiàn)觀察者模式：觀察者模式中 Model 通知 View 更新，實際上是 Model 對訂閱了自己的 View 提供操作方法的調(diào)用。

View，View 包含2部分：1）實現(xiàn)界面展示的 html+css；2）對外暴露的操作 View 的方法。
View -> Controller，用戶行為從視圖傳遞至控制器，有兩種方法：1）通過 html 標(biāo)簽的事件屬性如 onclick；2）JS中的addEventListener（非IE）/ attachEvent（IE）方法。（如JQuery的bind和angular的ng-click等都是對原生方法的封裝，等效于上述方法）
Controller，當(dāng)視圖發(fā)生用戶行為輸入時候，會進入控制器中的事件回調(diào)函數(shù)，在回調(diào)函數(shù)中，一般會對界面數(shù)據(jù)進行預(yù)處理（如：輸入校驗）、應(yīng)用邏輯處理（如：界面顯示Loading），然后調(diào)用對應(yīng)的 Model 方法進行模型更新操作。
Controller -> Model，Controller 的事件回調(diào)函數(shù)中調(diào)用 Model 的操作方法。
Model，Model 可理解為一個對象，對象的屬性就是抽象的數(shù)據(jù)模型，對象的方法就是對 Controller 暴露的操作方法。
Model -> View，Model 更新 View 使用觀察者模式，從JS實現(xiàn)上來說 Model 有個數(shù)組隊列中保存著訂閱（subscribe）了自己 View 的更新方法，Model 更新完畢后，遍歷并調(diào)用數(shù)組中的 View 更新方法即為發(fā)布（publish）。

OK，這就是 HTML+CSS+JS 實現(xiàn) 經(jīng)典MVC 的一個流程，下面我們說說它的優(yōu)缺點。

優(yōu)點：
1）職責(zé)分離思想，MVC三者各司其職，模塊化；
2）觀察者模式，實現(xiàn)單個Model可更新多視圖更新。

職責(zé)分離的優(yōu)點不用多說，代碼清晰易維護；觀察者模式實現(xiàn)單個數(shù)據(jù)模型，可同時更新多個視圖，擴展性良好。

缺點：
1）View依賴Model，不可避免引入業(yè)務(wù)邏輯，不易復(fù)用。

舉個栗子，model 和 view 如下：

????model 僅有 good/middle/bad 3種數(shù)據(jù)，view 基于此數(shù)據(jù)，需擴展顏色、圖例描述等系列業(yè)務(wù)邏輯，經(jīng)典MVC中，view 對外暴露渲染餅圖的方法，顏色這些業(yè)務(wù)的東東就被包含進去了，這就是我們說的不可避免引入業(yè)務(wù)邏輯。假設(shè)現(xiàn)在有新的 model2 含3種商品數(shù)量（顏色用黃、綠、藍），要復(fù)用餅圖 view，我們很容易想到，在 view 與 model 間加一層模型轉(zhuǎn)換就能很實現(xiàn)復(fù)用，但是經(jīng)典MVC中，model 與 view 之間是觀察者模式，那么模型轉(zhuǎn)換只能放到 view 中（model 一般不變），view 得擴展個新方法來滿足 model2。
????這個簡單例子也許不能很充分說明 View 依賴 Model 造成的問題，但可設(shè)想如果 View 的業(yè)務(wù)邏輯和應(yīng)用功能十分復(fù)雜，那么要適配不同的Model必然造成 View 的臃腫，一定程度后便難以復(fù)用。

我理解，現(xiàn)在大家常提及的 MVC 實際就是 MVP，它刷新界面一般遵循 V -> P -> M -> P -> V 的步驟。（MVP 模式將 Controller 改名為 Presenter，可等同視之）

用戶行為輸入，View 傳遞給 Presenter（在JS中通過事件監(jiān)聽實現(xiàn)）；Presenter 進行應(yīng)用邏輯處理，調(diào)用 Model 暴露的接口方法操作 Model；Model 更新完數(shù)據(jù)后傳遞給 Presenter（異步 Model 操作可使用 promise，讓Presenter在回調(diào)函數(shù)中獲得最新數(shù)據(jù)），Presenter 處理最新數(shù)據(jù)，調(diào)用 View 暴露的接口方法更新 View。

MVP 徹底分離了 View 與 Model，使用 HTML+CSS+JS 編碼，移除 MVC 觀察者模式，其余都很容易理解，在此不再贅述。

優(yōu)點：
1）解決View與Model耦合問題，使View變薄，更易復(fù)用。

請對應(yīng)參考上面 MVC 中的缺點1的例子。使用 MVP 后，Presenter 作為 View 和 Model 的中間層，那么 View 和 Model 僅需對外暴露標(biāo)準(zhǔn)接口，模型轉(zhuǎn)換的那些事兒，全部可以交給Presenter，View 層變薄，更容易復(fù)用。

缺點：
1）Presenter 承擔(dān)了V->M和M->V的應(yīng)用和業(yè)務(wù)邏輯，容易變得臃腫，可維護性降低。

MVVM 模式實際就是將 MVP 中的 Presenter 改名為 ViewModel，調(diào)用過程基本一致，最大的改良是 ViewModel 間的雙向綁定。

這里以實際項目中用過的 Angular1.x 為例，下圖僅為示意便于理解。

View 和 ViewModel 間，有一個對象 $scope，ViewModel 可以操作修改 $scope.data，View html 使用 $scope.data。當(dāng) ViewModel 設(shè)置 $scope.data=123 時，Angular框架會自動刷新 View 的顯示 123，同理當(dāng)界面有 input 這樣的入口時，修改 data 時，Angular框架也會自動刷新到 $scope.data 中。
【優(yōu)點】View 和 ViewModel 間的數(shù)據(jù)同步功能，部分被 Angular 框架承擔(dān)，部分解決了 MVP 中 Presenter 臃腫的問題，當(dāng)然編碼也會很方便。