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 爲例。

1. 用戶能夠向 View發送指令（DOM 事件），再由 View直接要求 Model 改變狀態。

2. 用戶也能夠直接向 Controller發送指令（改變 URL 觸發 hashChange 事件），再由 Controller發送給 View。

3. Controller很是薄，只起到路由的做用，而 View很是厚，業務邏輯都部署在 View。因此，Backbone索性取消了 Controller，只保留一個 Router（路由器） 。

MVP

MVP是對MVC的一種優化或者替代
來看兩幅圖


兩幅圖是不一樣的，可是對MVC的改進的思想倒是同樣的：切斷的View和Model的聯繫，讓View只和Presenter（原Controller）交互，減小在需求變化中須要維護的對象的數量。
MVP定義了Presenter和View之間的接口，讓一些能夠根據已有的接口協議去各自分別獨立開發，以此去解決界面需求變化頻繁的問題。上面兩圖都有接口，不過接口的實現和使用細節不同，不過思想上是一致的。
在這裏要提到的是，事實上，需求變化最頻繁的並不必定是最接近用戶的界面，但基本能夠肯定的是，最接近用戶的界面是由於需求變化而須要最頻繁更改的。固然，若是View若是是API而不是UI，那就另說了。
特色能夠總結爲：

1. 各部分之間的通訊，都是雙向的。

2. View與 Model不發生聯繫，都經過 Presenter傳遞。

3. 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 的圖示
知乎：你對MVC、MVP、MVVM 三種組合模式分別有什麼樣的理解？