MVP不好嗎？
- V：界面相關(guān)（界面的展示，用戶操作的觸發(fā)）
- M：數(shù)據(jù)相關(guān)（基本數(shù)據(jù)的定義，數(shù)據(jù)的處理：增刪該查）
- P：中介（是在M和V之間的中間商。拿到M給的數(shù)據(jù)，再小小的處理下，最后交給V）
從以上可以看出，mvp的邏輯還是很清楚的嘛！有哪里可以做的更好呢？
從P層扮演的中間商下手:
比如這樣的一個(gè)情況：
M層：從網(wǎng)絡(luò)獲取到了一堆新聞數(shù)據(jù)
P層：將M層獲取到的數(shù)據(jù)過(guò)濾一下（過(guò)濾掉不健康的信息）
V層：顯示P層過(guò)濾后的信息
我們可以將P層的將M層獲取到的數(shù)據(jù)過(guò)濾一下（過(guò)濾掉不健康的信息）
這個(gè)邏輯抽取出來(lái)，做成一個(gè)單獨(dú)的模塊！相當(dāng)于這個(gè)商業(yè)邏輯獨(dú)立了，針對(duì)這個(gè)邏輯，我們可以肆意的虐待他，比如測(cè)試（因?yàn)槭莻€(gè)單獨(dú)的模塊了，所有非常方便測(cè)試）！
將商業(yè)邏輯抽象
抽象：
抽象說(shuō)的太玄乎了，其實(shí)就是考慮將商業(yè)邏輯封裝成類(lèi)！
比如對(duì)人的相關(guān)信息可以封裝成Person，在clean架構(gòu)里，我們將商業(yè)邏輯封裝成UseCase
所謂商業(yè)邏輯其實(shí)就是：
針對(duì)你給的數(shù)據(jù)--->處理--->處理完成后的數(shù)據(jù)交出來(lái)
綜上：我們的UseCase就是如下啦：
UseCase
針對(duì)某個(gè)功能，你對(duì)P的分解，可以寫(xiě)出好幾個(gè)usecase啦：
限于篇幅，針對(duì)具體的
UseCase的實(shí)現(xiàn)，我就不細(xì)說(shuō)了，很簡(jiǎn)單的，你們細(xì)看。這個(gè)例子的地址：
https://github.com/android10/Android-CleanArchitecture
其它
你現(xiàn)在有一堆商業(yè)邏輯啦，一般商業(yè)邏輯的處理在后臺(tái)執(zhí)行，而處理后的結(jié)果需要切換到主線程。（Ok，我們有RxJava，很方便的來(lái)完成這個(gè)）
現(xiàn)在，我們用UseCaseHandler來(lái)解決這個(gè)問(wèn)題：(大同小易，可看可不看)
代碼我就補(bǔ)貼了，代碼地址在：
https://github.com/android10/Android-CleanArchitecture
