本文內(nèi)容提要：
記錄自己在公司Android客戶端項(xiàng)目中MVP架構(gòu)的使用經(jīng)歷。及對(duì)其的衍生的感悟。
涉及知識(shí)點(diǎn)：
閱讀時(shí)間：
5分鐘
為什么使用MVP：
如題，在MVP還沒出來前卓鹿，Android開發(fā)架構(gòu)基本屬于一個(gè)無序狀態(tài)。所有的邏輯、視圖氯葬、邏輯處理等處理都在一個(gè)Activity/Fragment中。在業(yè)務(wù)快速迭代中婉陷，這樣的開發(fā)模式會(huì)導(dǎo)致代碼越來越冗長帚称，維護(hù)與擴(kuò)展難度越來越大。舉個(gè)例子秽澳，在公司的項(xiàng)目中闯睹，未重構(gòu)前的商品詳情頁就多大4000行代碼。
MVP的好處之一就是能將視圖層肝集，數(shù)據(jù)層瞻坝，邏輯層解耦。維護(hù)成本與擴(kuò)展性就自然而然的解決了杏瞻。同時(shí)所刀，MVP的架構(gòu)最大的好處就是能執(zhí)行單元測(cè)試。不是說傳統(tǒng)的開發(fā)模式不能進(jìn)行單元測(cè)試捞挥。而是其組織架構(gòu)不夠整潔浮创。單元測(cè)試既混著視圖，又有邏輯砌函。而基于MVP的開發(fā)斩披，能夠讓對(duì)邏輯層單獨(dú)進(jìn)行JUnit+Mockito，而視圖層可以使用Espresso讹俊、Robolectric進(jìn)行單元測(cè)試垦沉。
MVP實(shí)踐路線：
- 一開始，我的MVP是針對(duì)View仍劈、Presenter厕倍、Data都寫一個(gè)接口。這樣開發(fā)下來贩疙，發(fā)現(xiàn)了這樣下會(huì)增加許多接口讹弯。接口過多也不是一個(gè)好的設(shè)計(jì)。
- 后來受到了Google Todo MVP 的影響这溅。將三層接口都整合到了Contact中
- 這一階段组民，我針對(duì)所有的數(shù)據(jù)傳輸，使用的是EventBus悲靴。因?yàn)樯婕暗蕉鄠€(gè)View需要監(jiān)聽同一個(gè)數(shù)據(jù)返回臭胜。本來想寫一個(gè)專門APT框架于這種情況的Bus框架。不過后來思考之后，開始讓View之間通過接口的形式相互傳遞數(shù)據(jù)比較合適庇楞。
- DTO（Data Transfer Object）與VO（View Object）榜配。一開始，MVP各層間的傳輸使用的是DTO吕晌〉叭欤可是如果字段變了，又需要修改三個(gè)文件睛驳。因此引入了VO可以將修改降低到最少烙心。
- 其實(shí)網(wǎng)上還有許多MVP的變種，比如把Activity變?yōu)镻層等乏沸。這些單從立意上淫茵，我就不是很贊成。因而作罷蹬跃。
感悟與總結(jié)：
MVP本質(zhì)上是面對(duì)接口編程的一種實(shí)現(xiàn)而已匙瘪。不需要把它的太重。而是不是所有業(yè)務(wù)都要用mvp呢蝶缀？一開始我是固執(zhí)的認(rèn)為需要的丹喻。想想所有的代碼都能那么干凈單純是會(huì)有多棒啊翁都！可是漸漸的碍论，我體會(huì)到這“過分的設(shè)計(jì)”的下場(chǎng)。首先柄慰，我寫的MVP鳍悠，對(duì)不懂MVP的同事來看，是不好維護(hù)的坐搔。其次藏研，在簡(jiǎn)單場(chǎng)景下使用，用mvp 反而增加了它的復(fù)雜度概行。某種意義上遥倦，是很不好維護(hù)的。
我意識(shí)到了過度設(shè)計(jì)的困擾占锯。不過，我反而感到慶幸缩筛。讓我及早領(lǐng)悟這個(gè)道理消略。
