基本上所有app的本質(zhì)說到底都是從網(wǎng)絡(luò)上獲取數(shù)據(jù)， 然后在View上顯示給用戶.

下面這張圖是一個(gè)概括性的對(duì)比架構(gòu)圖:

mvp_mvc.jpg

MVC 架構(gòu)的代碼

現(xiàn)在大多數(shù)的app架構(gòu)采用的是MVC架構(gòu)， Model(數(shù)據(jù))， View, Controler.
android的Activity在MVC架構(gòu)上就充當(dāng)了Controler的角色, 但作為用戶界面， 一定程度上也具有一定的View的角色.
MVC的開發(fā)模式， 典型的代碼結(jié)構(gòu)是在Activity類中調(diào)用model層來加載網(wǎng)絡(luò)數(shù)據(jù)， 然后把原數(shù)據(jù)進(jìn)行加工處理， 接下來設(shè)置給適當(dāng)?shù)腣iew展示給用戶。

這種模式下， 會(huì)出現(xiàn)2個(gè)問題.
一是， 會(huì)導(dǎo)致Activity類的代碼多于龐大， 經(jīng)常出現(xiàn)上千行的代碼, 代碼分析起來過于復(fù)雜. Activity作為Controler, 又作為View, 承擔(dān)了過多的職責(zé)， 違背了"單一職責(zé)"的設(shè)計(jì)原則.
二是， 把Activity作為View來看， View和Model數(shù)據(jù)之間相互引用， 耦合性強(qiáng), 無法實(shí)現(xiàn)2個(gè)模塊間的解藕.

MVP 架構(gòu)的代碼

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

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

一個(gè)最簡單的辨別方法

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

MVP 框架

主流框架: theMVP， beam
重要的是理解MVP的架構(gòu)思想，在theMVP框架下， Activity充當(dāng)Presenter的角色， ViewDelegate充當(dāng)View層的角色. Model還是固定不變的數(shù)據(jù)層.

MVP 框架的核心思想是:

1. View層和Model數(shù)據(jù)層不存在相互引用的關(guān)系.
2. MVP把Activity中UI邏輯抽象成View接口， 把業(yè)務(wù)邏輯抽象成Presenter接口, Model層還是原來的數(shù)據(jù)層.

典型案例

使用ListView 顯示一組數(shù)據(jù)

下面截取了幾張講座的關(guān)鍵截圖

1.jpg

2.jpg

3.jpg

4.jpg

refer to:
動(dòng)腦學(xué)院 架構(gòu)設(shè)計(jì) MVP 視頻

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