JavaScript大雜燴18 - Web開發的MVVM模式

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/，本身研究一下吧。