MVC,MVP,MVVM淺析
概述
M -V- X 本質都是一樣的 重點還是在于 M-V 的橋梁
要靠 X來牽線。
X的模式之間不同 主要是 M與V 的數據傳遞的流程不同。
數據傳遞的流程不同來源于運行環境技術棧能夠做到的事情不同。
所以無論是復雜化 簡單化 還是修改流程，基本都是因為技術棧變化了 對應做的調整。
在相同技術棧下 能夠實現的各種 X都可以是大同小異的。
在不同技術棧下 相同的X可能實現都大相徑庭，僅有非常抽象的流程類似。
前端框架演變
MVC
-
視圖（ View ）：用戶界面。
-
控制器（ Controller ）：業務邏輯
-
模型（ Model ）：數據保存
MVC 的一般流程是這樣的： View （界面）觸發事件--》 Controller （業務）處理了業務，然后觸發了數據更新--》不知道誰更新了 Model 的數據--》 Model （帶著數據）回到了 View --》 View 更新數據
缺陷：在 MVC ，當你有變化的時候你需要同時維護三個對象和三個交互，這顯然讓事情復雜化了。
實例： Backbone
實際項目往往采用更靈活的方式，以 Backbone.js 為例。
-
用戶可以向 View 發送指令（DOM 事件），再由 View 直接要求 Model 改變狀態。
-
用戶也可以直接向 Controller 發送指令（改變 URL 觸發 hashChange 事件），再由 Controller 發送給 View 。
-
Controller 非常薄，只起到路由的作用，而 View 非常厚，業務邏輯都部署在 View 。所以， Backbone 索性取消了 Controller ，只保留一個 Router （路由器） 。
MVP
MVP 是對 MVC 的一種優化或者替代
來看兩幅圖
兩幅圖是不同的，但是對 MVC 的改進的思想卻是一樣的：切斷的 View 和 Model 的聯系，讓 View 只和 Presenter （原 Controller ）交互，減少在需求變化中需要維護的對象的數量。
MVP 定義了 Presenter 和 View 之間的接口，讓一些可以根據已有的接口協議去各自分別獨立開發，以此去解決界面需求變化頻繁的問題。 上面兩圖都有接口，不過接口的實現和使用細節不一樣，不過思想上是一致的。
在這里要提到的是， 事實上，需求變化最頻繁的并不一定是最接近用戶的界面，但基本可以確定的是，最接近用戶的界面是因為需求變化而需要最頻繁更改的。 當然，如果 View 如果是API而不是UI，那就另說了。
特點可以總結為：
-
各部分之間的通信，都是雙向的。
-
View 與 Model 不發生聯系，都通過 Presenter 傳遞。
-
View 非常薄，不部署任何業務邏輯，稱為"被動視圖"（Passive View），即沒有任何主動性，而 Presenter 非常厚，所有邏輯都部署在那里。
MVVM
ViewModel 大致上就是 MVP 的 Presenter 和MVC的 Controller 了，而 View 和 ViewModel 間沒有了 MVP 的界面接口，而是直接交互，用數據“綁定”的形式讓數據更新的事件不需要開發人員手動去編寫特殊用例，而是自動地雙向同步。數據綁定你可以認為是Observer模式或者是Publish/Subscribe模式，原理都是為了用一種統一的集中的方式實現頻繁需要被實現的數據更新問題。
比起 MVP ， MVVM 不僅簡化了業務與界面的依賴關系，還優化了數據頻繁更新的解決方案，甚至可以說提供了一種有效的解決模式。
Angular 和 Ember 都采用這種模式。
實際上，現在 Web MVVM 主要并不是用在了 Web 或者 Wap 上，而是移動 App 上。按照前面的說法，只可能是：
HTML+JS 比原生在一些場景上更適合 Native
在移動 App 上比Web上更適合使用MVVM
哪怕是 Native 開發，實際上 iOS 的開發上也是用類似的數據綁定的方式的。這里也不深究了，畢竟我也不算懂 iOS 。
要說的是，在 Web MVVM 或者 Web 的模式上，也就是 Web 的富應用上，現在還不過是個初期由膨脹的需求推動的階段。重要的不是技術會怎么走，而是需求和客觀條件會怎么走。
參考資料
你對MVC、MVP、MVVM 三種組合模式分別有什么樣的理解？
來自：https://segmentfault.com/a/1190000006840458