要交待清楚mvvm(Model-View-ViewModel)框架，就有必要交待一下mvvm的由來，今生，以及來世。那好，首先感謝大家，我們慢慢來 - - >
我想MVC – > MVP – > MVVM 應該有一個衍變過程
MVC:
這裏就以Android爲例 ：
View: XML佈局文件，自定義View
Model:實體模型(數據的獲取、存儲、數據狀態變化)
Controller：對應的Activity，Fragment等，處理數據、業務、UI等
這裏，我們就會產生分歧了，activity等的不是可以放在view層嗎？項目分包時，將activity放在view層，那不是我們的view和model不就可以連線了？
事實上，Android本身的設計還是符合MVC架構的，但是Android中純粹作爲View的XML試圖功能太弱，我們大量處理View的邏輯只能寫在Activity中。這樣Activity就充當了View和Controller兩個角色。之後我們開發中的代碼動輒千行，我想大家都遇到過……
於是，在與四大組件中Service相較而論，帶UI組件的Activiy，作爲UI功能的載體，自然可以作爲View。於是，
MVP:
我能爲了把activity、fragment等作爲單純意義上的視圖層，而 邏輯處理，放在一個單獨的類裏，取名叫做Presenter
View:對應於Activity、Fragment和XML，負責View的繪製以及與⽤戶交互
Model:依然是實體模型
Presenter:負責完成View與Model間的交互和業務邏輯
相比MVC我們的MVP更加方便靈活，可以整體架構採用MVP，也可以單一業務線採用MVP。爲了降低Presenter和View之間的依賴關係，MVP 還提倡通過⼀個抽象的View接⼝（不是真正的View層）將 Presenter 與真正的View層進⾏解耦。Persenter持有該View接⼝對象，對該接⼝進⾏操作，⽽不是直接操作View層。這樣View層對Presenter 層的依賴變成了單⽅向的依賴，View 的變化不會傳遞到 Presenter 層來(後期view需求變更，不會直接影響presenter層的大幅度變動，這裏也不詳細敘述低耦合高內聚的事情了，軟件開發的基本常識)。更有甚者提倡爲View、Presenter、Model 都定義抽象的接⼝。
這裏我們就不再深入細說了，要跑題了啊。。。（改日再撩） ^ ^
往往，魚和熊掌不可兼得，MVP解決問題的同時，也會帶來新的問題 - - >①大量接口帶來的代碼碎片化（面向接口編程的通病） ② MVP是UI驅動式模型。對於UI輸入引起數據變化，又或者數據變動引起UI的變化，就需要我們手動調用P層接口或V層接口，需要考慮大量的問題（UI變化是否在主線程等等…），顯得過於繁瑣。
於是。。
MVVM:
View:對應於Activity、Fragment和XML，負責View的繪製以及與⽤戶交互，⽐較複雜的動畫效果等都可以放在Activity中
Model:還是實體模型
ViewModel:負責完成View與Model間的交互，負責業務邏輯
MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model），有幾大優點
① 低耦合。視圖（View）可以獨立於Model變化和修改，一個ViewModel可以綁定到不同的”View”上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
② 可重用性。你可以把一些視圖邏輯放在一個ViewModel裏面，讓很多view重用這段視圖邏輯。
③ 獨立開發。開發人員可以專注於業務邏輯和數據的開發（ViewModel），設計人員可以專注於頁面設計，使用Expression Blend可以很容易設計界面並生成xml代碼。
④ 可測試。界面素來是比較難於測試的，而現在測試可以針對ViewModel來寫。
細心的同學發現，我們把vm層改成presenter不就是MVP
嗎。其實MVVM就是MVP的衍化，不過她採用了雙向綁定機制哦，時V層與M層交互不再頻繁使用接口式編程我們所考慮的問題更少了，我們專注於設計和用戶體驗
哈哈，那麼
關於DataBing我們下期見
