參考鏈接CSDN網友博客
博客園網友總結 http://www.cnblogs.com/John-Chen/p/4458823.html
MVC模式
最主要的是得想辦法做到解耦以及提升應用的穩定性。
- MVC 是Model、View、Controller 三部分組成的。其中View 主要由xml 佈局文件，或者用代碼編寫動態佈局來體現。Model 是數據模型，其實類似javabean，不過這些JavaBean 封裝了對數據庫、網絡等的操作。Controller 一般由Activity 負責，它根據用戶的輸入，控制用戶界面數據的顯示及更新model 對象的狀態，它通過控制View 和Model 跟用戶進行交互。
MVC與Android的各個組件的對應關係：
- View：自定義View或ViewGroup，負責將用戶的請求通知Controller，並根據model更新界面；
- Controller：Activity或者Fragment，接收用戶請求並更新model；
- Model：數據模型，負責數據處理相關的邏輯，封裝應用程序狀態，響應狀態查詢，通知View改變，對應Android中的datebase、SharePreference等。
![]()
視圖（View）：用戶界面。
- 控制器（Controller）：業務邏輯
- 模型（Model）：數據保存
各部分之間的通信方式如下
所有的通信都是單向的
- View 傳送指令到 Controller
- Controller 完成業務邏輯後，要求 Model 改變狀態
- Model 將新的數據發送到 View，用戶得到反饋
對於android本身來說，其界面部分的開發就涉及到了模型—視圖—控制器3者的交互，在android中視圖View層一般採用XML文件進行界面的描述；而對於模型model部分則大多對應於本地的數據文件或網絡獲取的數據體，很多情況下我們對這些數據的處理也會在這一層中進行；最後的控制器Controller部分則由Activity承擔。
一般情況下，在Activity中獲取數據以及界面元素，並將兩者進行綁定，但其邏輯不能過於複雜，因爲android中規定一個Activity的響應時間是5秒，如果超過這個時間可能會被回收掉。
在Android 的UI 系統中，控制器Activity 主要起到的作用就是解耦，將視圖View 和模型Model 進行分離，兩者在Activity 中進行綁定或完成其他邏輯。總體來說， MVC 更適合於規模比較大的項目
相關資料可參閱這裏的三篇博客
MVP模式（Model View Presenter）
MVP 模式將 Controller 改名爲 Presenter（主持人、中間人），同時改變了通信方向。
MVP模式的三個角色
Presenter一一交互中間人
Presenter 主要作爲溝通View 和Model 的橋樑，它從Model 層檢索數據後，返回給View 層，使得View 和Model 之間沒有耦合，也將業務邏輯從View 角色上抽離出來。
View一一用戶界面
View 通常是指Activity 、Fragment 或者某個View 控件，它含有一個Presenter 成員變量。通常View 需要實現一個邏輯接口，將View 上的操作通過會轉交給Presenter 進行實現，最後， Presenter調用View 邏輯接口將結果返回給View 元素。
Model一一數據的存取
對於一個結構化的App 來說， Model 角色主要是提供數據的存取功能。Presenter 需要通過Model層存儲、獲取數據， Model 就像一個數據倉庫。更直白地說， Model 是封裝了數據庫DAO 或者網絡獲取數據的角色，或者兩種數據獲取方式的集合。
由此可見Model-View一－Presenter 三者之間的關係都是鬆耦合， Presenter 持有的View 、Model 引用都是抽象，這樣當UI發生變化時，我們只需要替換View 即可；而數據庫引擎需要替換時，只需要重新構建一個實現ArticleModel 接口的類實現相關的存取邏輯即可。這樣使得View 、Model 、Presenter三者之間可以獨立的變化，測試也非常方便，可擴展性、靈活性都很高
各部分之間的通信，都是雙向的。
View 與 Model 不發生聯繫，都通過 Presenter 傳遞。
View 非常薄，不部署任何業務邏輯，稱爲”被動視圖”（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那裏。
MVP 模式會解除View 與Model 的耦合，同時又帶來了良好的可擴展性、可測試性，保證了系統的整潔性、靈活性。
MVP 模式可以分離顯示層和邏輯層，它們之間通過接口進行通信，降低糯合。
理想化的MVP模式可以實現同一份邏輯代碼搭配不同的顯示界面，因爲它們之間並不依賴於具體，而是依賴於抽象。這使得Presenter 可以運用於任何實現了View 邏輯接口的UI ，使之具有更廣泛的適用性，保證了靈活度。
對於一個可擴展、穩定的應用來說，我們需要定義分離各個層， 主要是UI層、業務邏輯層和數據層。
MVP 並不是一個標準化的模式，它有很多種實現方式,只要保證我們是通過Presenter 將View 和Model 解耦合、降低類型複雜度、各個模塊可以獨立測試、獨立變化，這就是正確的方向。
MVC 的耦合性還是相對較高， View 可以直接訪問Model ，導致3 者之間構成迴路。因此， MVP 與MVC 的主要區別是， MVP 中的View 不能直接訪問Model ，需要通過Presenter 發出請求， View 與Model 不直接通信。
MVVM模式
MVVM 與MVP 非常相似，唯一的區別是View 和Model 進行雙向綁定（ data-binding ），兩者之間有一方發生變化則會反應到另一方上。而MVP 與MVVM 的主要區別則是， MVP 中的View更新需要通過Presenter，而MVVM 則不需要，因爲View 與Model 進行了雙向綁定，數據的修改會直接反應到View 角色上，而View 的修改也會導致數據的變更。此時， ViewModel 角色需要做的只是業務邏輯的處理，以及修改View 或者Model 的狀態。MVVM 模式有點像ListView 與Adapter 、數據集的關係，這個Adapter 就是ViewModel 角色，它與View 進行了綁定，又與數據集進行了綁定，當數據集合發生變化時，調用Adapter 的notifyDataSetChanged 之後View 就直接更新，它們之間沒有直接的耦合，使得ListView 變得更爲靈活。
MVVM 模式將 Presenter 改名爲 ViewModel，基本上與 MVP 模式完全一致。