MVC VS. MVP VS. MVVM
了解MVVM模式之前，我們先來簡單了解一下從MVC到MVVM的變遷。這個變遷是耦合從緊到松的變遷，是對依賴處理的進化，是應對變化技術的成熟。
MVC
MVC全名是Model View Controller， 是模型(model)－視圖(view)－控制器(controller)的縮寫，它用一種將業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。將系統進行MVC分層的核心思路就是分離組件，降低組件耦合性，組件獨立演化。
MVC模式可以使用下面這幅圖來描述各個部分的作用以及與其他組件的交互過程： 
MVC模式的優點很明顯，那就是耦合性低，重用性高，應對每個組件的變化性好，便於開發，測試與維護。但是MVC模式也還是有缺點的，給系統帶來的額外復雜性自然不必說了，此外，MVC三個組件的定義存在一定的模糊性，這樣就衍生了很多的比如主動MVC，被動MVC等實施方案，每種方案中MVC三大組件的功能都不太一樣，比如有的把業務邏輯放到Model部分，Controller只不過是把用戶輸入轉換一下，直接傳給Model來處理，Model是整個系統的核心部分，上面這幅圖就是這樣的(這種情況其實就是真正的MVC模式的定義)，還有的方案把業務邏輯直接放到了Controller中，Model只負責處理數據。而且在不同的方案中，要么View與Controller耦合過於緊密，要么View訪問Model的時候比較低效，要么Model由於要與View直接打交道，導致了Model與View直接耦合在了一起，而Model發生變化的時候會牽連View一起變化，這卻恰恰違背了MVC組件分層的本意。
MVP
MVP的全稱為Model-View-Presenter，Model提供數據，View負責顯示，Presenter負責邏輯的處理。MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter來進行的，所有的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過Controller。
MVP模式可以使用下面這幅圖來描述各個部分的作用以及與其他組件的交互過程： 
在MVC里，我們談到它的缺點主要有兩個：
一個是MVC三大組件的定義比較模糊。這個在MVP中就相對明確一些了：Model只負責處理最終數據；View就是很薄的一層，只顯示數據，通常認為，View只應該有簡單的Set/Get的方法，View只負責用戶輸入和設置界面顯示的內容，除此就不應該有更多的內容，絕不容許直接訪問Model；所有業務邏輯都由Presenter處理，而且，Presenter與具體的View和Model是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View或者Model具體實現的時候可以保持Presenter的不變，這樣就實現了業務邏輯的重用。
另一個是View與Model的緊密耦合。在MVC中，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。所以，在MVC模型里，Model不依賴於View，但是View是依賴於Model的。不僅如此，因為有一些業務邏輯在View里實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
在現實中，MVP的實現會根據View的充、貧血而有一些不同，一部分傾向於在View中放置簡單的邏輯，在Presenter放置復雜的邏輯；另一部分傾向於在presenter中放置全部的邏輯。這兩種分別被稱為：Passive View和Superivising Controller。
在Passive View中，為了減少UI組件的行為，使用Controller不僅控制用戶事件的響應，而且將結果更新到View上。可以集中測試Controller，減小View出問題的風險。
在Superivising Controller中的Controller既處理用戶輸入的響應，又操作View處理View的復雜邏輯。
MVP解決了MVC的一些問題，其實現在說到MVC，通常指的也就是MVP。但是MVP也是不完美的，由於Presenter可以反作用於View，這樣View的渲染有可能就放在了Presenter中，所以View和Presenter的交互會過於頻繁。如果Presenter過多地渲染了View，往往會使得它與特定的View的聯系過於緊密。一旦View需要變更，那么Presenter也需要變更了。
MVVM
MVVM全稱Model-View-ViewModel，Model提供數據，View負責顯示，這個還和MVP一樣，這個模式的重點就是ViewModel的部分，它通過雙向綁定(松耦合)解決了MVP中Presenter與View聯系比較緊密的問題。
MVVM模式可以使用下面這幅圖來描述各個部分的作用以及與其他組件的交互過程： 
從圖中我們可以看到MVVM與MVP最大的不同就在於View與ViewModel交互的時候使用了松耦合的雙向綁定，而不是像View與Presenter那樣直接交互。ViewModel作為View的數據映射，通常View上有什么屬性，ViewModel上也會存在相應的一個屬性，這兩個屬性通過事件實現了雙向的綁定，常見的MVVM框架都替我們完成了這樣的綁定過程。
MVVM最初是微軟在WPF中實現的模式，隨之在Web開發中也開始了MVVM風潮，這里介紹的3個MVVM框架就是我認為比較典型的幾個。
微軟的前端框架knockoutjs
這是一個獨立的前端MVVM框架，也是最早的前端MVVM框架，它完成了頁面的數據與界面之間的雙向綁定，至於真正這些數據是通過何種手段(比如Ajax)獲取到的，它並不關心。這是一個只關注前端邏輯與界面解耦的純前端類庫，理論上可以搭配任何的后台技術，來完成整個網站的建設。這是我第一個學習的MVVM框架，使用它給我的感覺是相當良好：綁定好了自動雙向更新是多么酷的特性啊。
下面是比較火熱的幾個學習教程：
http://knockoutjs.com/
http://www.cnblogs.com/TomXu/archive/2011/11/21/2257154.html
http://www.cnblogs.com/lori/p/3552571.html
谷歌的全套服務angularjs
這是一個比較龐大，但是也無比強大的前端MVVM類庫，天生對RESTful API的良好支持，雙向綁定的優良特性，專業的HTML模板擴展支持，全面的測試框架，與Bootstrap，Nodejs的完美融合，再加上Google的金字招牌，你可以拒絕么？
下面是比較火熱的教程：
https://angularjs.org/
http://www.ituring.com.cn/minibook/303
http://www.iteye.com/news/28651-AngularJS-Google-resource
http://woxx.sinaapp.com/
http://www.angularjs.cn/tag/AngularJS
最迷你的MVVM框架avalon
這確實是最mini的MVVM框架，與Angularjs不一樣，它側重數據結構的設計，提倡簡單的算法，它是在吸收上面兩個類庫的基礎上發展起來的，而且符合國情，支持IE6，難道不值得期待？
下面是比較好的教程：
http://rubylouvre.github.io/mvvm/
http://limodou.github.io/avalon-learning/zh_CN/index.html
http://www.cnblogs.com/rubylouvre/p/3181291.html
http://www.oschina.net/p/avalon
http://www.iteye.com/topic/1130359
http://www.tuicool.com/articles/NrMrIn
最后附送一個有意思的網站：http://todomvc.com/，自己研究一下吧。