在MVP中:
Presenter完全把Model和View進(jìn)行了分離,主要的程序邏輯在Presenter里實(shí)現(xiàn)。其中的View是很薄的一層。
Presenter與具體的View是沒有直接關(guān)聯(lián)的,而是通過定義好的接口進(jìn)行交互,從而使得在變更View時(shí)候可以保持Presenter的不變,即重用!
當(dāng)我們將其中復(fù)雜的邏輯處理移至另外的一個(gè)類(Presneter)中時(shí),Activity其實(shí)就是MVP模式中View,它負(fù)責(zé)UI元素的初始化,建立UI元素與Presenter的關(guān)聯(lián)(Listener之類),同時(shí)自己也會(huì)處理一些簡(jiǎn)單的邏輯(復(fù)雜的邏輯交由Presenter處理).
1、方便測(cè)試:
回想一下你在開發(fā)Android應(yīng)用時(shí)是如何對(duì)代碼邏輯進(jìn)行單元測(cè)試的?是否每次都要將應(yīng)用部署到Android模擬器或真機(jī)上,然后通過模擬用戶操作進(jìn)行測(cè)試?然而由于Android平臺(tái)的特性,每次部署都耗費(fèi)了大量的時(shí)間,這直接導(dǎo)致開發(fā)效率的降低。而在MVP模式中,處理復(fù)雜邏輯的Presenter是通過interface與View(Activity)進(jìn)行交互的,這說明了什么?說明我們可以通過自定義類實(shí)現(xiàn)這個(gè)interface來模擬Activity的行為對(duì)Presenter進(jìn)行單元測(cè)試,省去了大量的部署及測(cè)試的時(shí)間。
我們還可以編寫測(cè)試用的View,模擬用戶的各種操作,從而實(shí)現(xiàn)對(duì)Presenter的測(cè)試 —— 而不需要使用自動(dòng)化的測(cè)試工具。
我們甚至可以在Model和View都沒有完成時(shí)候,就可以通過編寫Mock Object(即實(shí)現(xiàn)了Model和View的接口,但沒有具體的內(nèi)容的)來測(cè)試Presenter的邏輯。
2、如果View很簡(jiǎn)單:
有人提出了Presenter First的設(shè)計(jì)模式,就是根據(jù)User Story來首先設(shè)計(jì)和開發(fā)Presenter。在這個(gè)過程中,能夠把信息顯示清楚就可以了。在后面,根據(jù)需要再隨便更改View,而對(duì)Presenter沒有任何的影響了。
3、如果UI比較復(fù)雜,而且相關(guān)的顯示邏輯還跟Model有關(guān)系,就可以在View和Presenter之間放置一個(gè)Adapter。
由這個(gè) Adapter來訪問Model和View,避免兩者之間的關(guān)聯(lián)。
而同時(shí),因?yàn)锳dapter實(shí)現(xiàn)了View的接口,從而可以保證與Presenter之間接口的不變。
這樣就可以保證View和Presenter之間接口的簡(jiǎn)潔,又不失去UI的靈活性。
在MVP模式里,View只應(yīng)該有簡(jiǎn)單的Set/Get的方法,用戶輸入和設(shè)置界面顯示的內(nèi)容,除此就不應(yīng)該有更多的內(nèi)容,絕不容許直接訪問Model —— 這就是與MVC很大的不同之處。