### 參考鏈接
* [簡述MVC框架模式以及在你（ANDROID）項目中的應用](http://www.cnblogs.com/John-Chen/p/4458823.html)
* [【譯】Android開發中的MVP架構](http://www.imooc.com/article/3141)
* [安卓項目中MVP模式實踐](http://www.imooc.com/article/1812)
### MVC模式 ###
最主要的是得想辦法做到解耦以及提升應用的穩定性。
* **MVC 是Model、View、Controller 三部分組成的。其中View 主要由xml 布局文件，或者用代碼編寫動態布局來體現。Model 是數據模型，其實類似javabean，不過這些JavaBean 封裝了對數據庫、網絡等的操作。Controller 一般由Activity 負責，它根據用戶的輸入，控制用戶界面數據的顯示及更新model 對象的狀態，它通過控制View 和Model 跟用戶進行交互。**
* MVC是一種框架模式，而不是設計模式，GOF把MVC看做3種設計模式，觀察者模式、策略模式、組合模式，其核心在觀察者模式。
* 框架模式與設計模式的區別
* 對于框架模式來說，是對代碼的重用；而對于設計來說通常是對設計的重用。
* 框架面向于一系列相同行為代碼的重用；而設計則面向的是一系列相同結構代碼的重用，架構介于框架和設計之間
- 在軟件開發領域有3種級別的重用
- 內部重用
- 代碼重用
- 應用框架的重用
常見的框架模式有：MVC、MVVC、MTV、CBD、ORM、MVP
簡而言之：**框架是大智慧，用來對軟件設計進行分工，設計模式是小技巧，對具體問題提出解決方案，以提高代碼復用率，降低耦合度**
* MVC與Android的各個組件的對應關系：
* View：自定義View或ViewGroup，負責將用戶的請求通知Controller，并根據model更新界面；
* Controller：Activity或者Fragment，接收用戶請求并更新model；
* Model：數據模型，負責數據處理相關的邏輯，封裝應用程序狀態，響應狀態查詢，通知View改變，對應Android中的datebase、SharePreference等。
* 視圖（View）：用戶界面。
* 控制器（Controller）：業務邏輯
* 模型（Model）：數據保存
#### 各部分之間的通信方式如下 ####
所有的通信都是單向的
1. View 傳送指令到 Controller
2. Controller 完成業務邏輯后，要求 Model 改變狀態
3. Model 將新的數據發送到 View，用戶得到反饋
對于android本身來說，其界面部分的開發就涉及到了模型---視圖---控制器3者的交互，在android中視圖View層一般采用XML文件進行界面的描述；而對于模型model部分則大多對應于本地的數據文件或網絡獲取的數據體，很多情況下我們對這些數據的處理也會在這一層中進行；最后的控制器Controller部分則由Activity承擔。
**一般情況下，在Activity中獲取數據以及界面元素，并將兩者進行綁定，但其邏輯不能過于復雜，因為android中規定一個Activity的響應時間是5秒，如果超過這個時間可能會被回收掉。**
在Android 的UI 系統中，控制器Activity 主要起到的作用就是解耦，將視圖View 和模型Model 進行分離，兩者在Activity 中進行綁定或完成其他邏輯。總體來說， MVC 更適合于規模比較大的項目
相關資料可參閱[這里](http://isux.tencent.com/learn-android-from-zero-session3.html)的三篇博客
### MVP模式（Model View Presenter） ###
MVP 模式將 Controller 改名為 Presenter（主持人、中間人），同時改變了通信方向。
#### MVP模式的三個角色 ####
1. Presenter一一交互中間人
Presenter 主要作為溝通View 和Model 的橋梁，它從Model 層檢索數據后，返回給View 層，使得View 和Model 之間沒有耦合，也將業務邏輯從View 角色上抽離出來。
2. View一一用戶界面
View 通常是指Activity 、Fragment 或者某個View 控件，它含有一個Presenter 成員變量。通常View 需要實現一個邏輯接口，將View 上的操作通過會轉交給Presenter 進行實現，最后， Presenter調用View 邏輯接口將結果返回給View 元素。
3. Model一一數據的存取
對于一個結構化的App 來說， Model 角色主要是提供數據的存取功能。Presenter 需要通過Model層存儲、獲取數據， Model 就像一個數據倉庫。更直白地說， Model 是封裝了數據庫DAO 或者網絡獲取數據的角色，或者兩種數據獲取方式的集合。
**由此可見Model-View一－Presenter 三者之間的關系都是松耦合， Presenter 持有的View 、Model 引用都是抽象，這樣當UI發生變化時，我們只需要替換View 即可；而數據庫引擎需要替換時，只需要重新構建一個實現ArticleModel 接口的類實現相關的存取邏輯即可。這樣使得View 、Model 、Presenter三者之間可以獨立的變化，測試也非常方便，可擴展性、靈活性都很高**
1. 各部分之間的通信，都是雙向的。
2. View 與 Model 不發生聯系，都通過 Presenter 傳遞。
3. 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 模式完全一致。
