淺談Android開發中的MVVM模式及與MVP和MVC的區別
三種架構模式的演化：
什麼是MVVM？
MVVM是Model-View-ViewModel的簡寫。微軟的WPF帶來了新的技術體驗，如Silverlight、音訊、視訊、3D、動畫……，這導致了軟體UI層更加細節化、可定製化。同時，在技術層面，WPF也帶來了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足於原有MVP框架並且把WPF的新特性糅合進去，以應對客戶日益複雜的需求變化。
MVC和MVP的關係
MVP是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數 據，View負責顯示。作為一種新的模式，MVP與MVC有著一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是通過 Presenter (MVC中的Controller)來進行的，所有的互動都發生在Presenter內部，而在MVC中View會直接從Model中讀取資料而不是通過 Controller。
MVVM和MVP的關係
而 MVVM 模式將 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一致。 唯一的區別是，它採用雙向繫結（data-binding）：View的變動，自動反映在 ViewModel，反之亦然。這樣開發者就不用處理接收事件和View更新的工作。
具體分析
MVC架構：
View：對應於佈局檔案
Model：業務邏輯和實體模型
Controllor：對應於Activity
View是可以直接訪問Model，View裡會包含Model資訊，不可避免的還要包括一些業務邏輯。Controller是基於行為的，並且可以被多個View共享。在MVC模型裡，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。Model不依賴於View，但是 View是依賴於Model。
MVP架構：
View： 對應於Activity，負責View的繪製以及與使用者互動
Model： 依然是業務邏輯和實體模型
Presenter： 負責完成View於Model間的互動
View不直接與Model互動，而是通過與Presenter互動來與Model間接互動。Presenter與View的互動是通過介面來進行的。通常View與Presenter是一對一的，但複雜的View可能繫結多個Presenter來處理邏輯
MVP的優點
1、Model與View完全分離，修改互不影響
2、更高效地使用，因為所有的邏輯互動都發生在一個地方—Presenter內部
3、一個Preseter可用於多個View，而不需要改變Presenter的邏輯（因為View的變化總是比Model的變化頻繁）。
4、更便於測試。把邏輯放在Presenter中，就可以脫離使用者介面來測試邏輯（單元測試）
MVVM架構：
Model：代表你的基本業務邏輯
View：顯示內容
ViewModel：將前面兩者聯絡在一起的物件
一個ViewModel介面提供了兩個東西：動作和資料。動作改變Model的下層（click listener，監聽文字改變的listener等等），而資料則是Model的內容。
在MVVM中，View/Model的變動，自動反映在 ViewModel，反之亦然。這兩個元件只是通過ViewModel鬆耦合在一起。這種設計模式之所以好用和方便，除了明顯智慧化了的View之外，還方便了測試。因為ViewModel不在依賴於View了，你可以在沒有View的情況下也能測試ViewModel。在合適的依賴注入的幫助下，測試就會變得非常簡單。
MVVM的優點
低耦合。檢視（View）可以獨立於Model變化和修改，一個ViewModel可以繫結到不同的”View”上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
可重用性。你可以把一些檢視邏輯放在一個ViewModel裡面，讓很多view重用這段檢視邏輯。
獨立開發。開發人員可以專注於業務邏輯和資料的開發（ViewModel），設計人員可以專注於頁面設計。
可測試。介面素來是比較難於測試的，而現在測試可以針對ViewModel來寫
總結：
任何的專案框架，都是為專案服務的。沒有絕對的好壞之分，只有更合適的選擇。在專案進展的不同階段，做出最合適的調整，才是是更適合團隊專案發展的框架。專案設計者要謹記，任何的專案設計，都是要圍繞專案發展階段，團隊成員規模，和團隊整體能力而定的。切莫為了設計而設計，為了框架而框架。快速，高效的配合整個團隊進展專案，才是最合適的架構。才是一個程式設計師為成一個leader，成為一個架構師的必經之路。