基本上所有app的本質說到底都是從網絡上獲取數據， 然后在View上顯示給用戶.

下面這張圖是一個概括性的對比架構圖:

mvp_mvc.jpg

MVC 架構的代碼

現在大多數的app架構采用的是MVC架構， Model(數據)， View, Controler.
android的Activity在MVC架構上就充當了Controler的角色, 但作為用戶界面， 一定程度上也具有一定的View的角色.
MVC的開發模式， 典型的代碼結構是在Activity類中調用model層來加載網絡數據， 然后把原數據進行加工處理， 接下來設置給適當的View展示給用戶。

這種模式下， 會出現2個問題.
一是， 會導致Activity類的代碼多于龐大， 經常出現上千行的代碼, 代碼分析起來過于復雜. Activity作為Controler, 又作為View, 承擔了過多的職責， 違背了"單一職責"的設計原則.
二是， 把Activity作為View來看， View和Model數據之間相互引用， 耦合性強, 無法實現2個模塊間的解藕.

MVP 架構的代碼

Model --- View --- Presenter
在MVP架構下， android的Activity類就只單純的承擔View的角色， 在Activity類中不做任何的數據處理, 當然也沒有model數據層的引用, 只負責展示UI的工作. 職能單一， 符合"單一職責"的設計原則.
Activity對外提供的功能通過一個IActivity接口聲明, Activity和Presenter之間相互引用. Activity直接引用Presenter的對象, Presenter中以IActivity接口的形式引用Activity的對象.
在Presenter中引用Model的對象， 執行數據的訪問.
通過以上的架構可以看到， 作為單純View角色的Activity和Model之間不存在引用關系, 兩者實現了解藕. 更關鍵的是Activity只負責展示UI的工作， 代碼簡潔， 不會再出現上千行代碼的情況.

此外， 把Acitivity抽象為某個接口還有一個好處是， 這個Activity能做哪些ui操作就一目了然了.

一個最簡單的辨別方法

拿到一份新代碼， 如果Activity類的代碼行數超過幾百行， 那基本就是采用傳統上的MVC架構， 如果Activity的代碼很簡潔， Activity實現了一個接口， 接口里面定義了UI操作的一組方法，Activity類的大部分代碼都是實現這個接口中聲明的方法, 那基本上就是采用的MVP架構.

MVP 框架

主流框架: theMVP， beam
重要的是理解MVP的架構思想，在theMVP框架下， Activity充當Presenter的角色， ViewDelegate充當View層的角色. Model還是固定不變的數據層.

MVP 框架的核心思想是:

1. View層和Model數據層不存在相互引用的關系.
2. MVP把Activity中UI邏輯抽象成View接口， 把業務邏輯抽象成Presenter接口, Model層還是原來的數據層.

典型案例

使用ListView 顯示一組數據

下面截取了幾張講座的關鍵截圖

1.jpg

2.jpg

3.jpg

4.jpg

refer to:
動腦學院 架構設計 MVP 視頻

------DONE.--------