目前關(guān)于mvp架構(gòu)實現(xiàn)的例子相當(dāng)之多官觅，這里總結(jié)了一下社區(qū)對于mvp架構(gòu)實現(xiàn)的幾點忠告。
假如你打算將MVP模式引入到你的項目中洋闽，那么你將不得不去面對android開發(fā)中常見的一些問題玄柠，如Activity的生命周期及以下：
- 是否該保存presenter的狀態(tài)
- 是否該持久化presenter
- presenter是否應(yīng)該有生命周期
3個問題，本文將圍繞這些常見的問題展開討論诫舅，順便給出一些best practice 和 guidelines羽利。
首先來看一下，MVP三個角色之前的關(guān)系圖吧骚勘。
MVP設(shè)計模式
- Model：負(fù)責(zé)管理數(shù)據(jù)的铐伴。從細(xì)的方面說撮奏，使用
RESTFUL API,緩存數(shù)據(jù)，操作數(shù)據(jù)庫当宴，讀寫pref等等畜吊，都應(yīng)該是Model的職責(zé)范圍。業(yè)界對于Model的實現(xiàn)户矢，有兩種方式玲献，個人覺得都是合理的。對于Repository pattern 黨梯浪，model可能是Repository捌年，而對于Clean architecture 黨 model可能是Interactor，然而挂洛，這都沒有什么問題礼预。 - Presenter：負(fù)責(zé)給Model和View牽線搭橋的，可以理解為中間人虏劲，他阻斷了Model和View直接溝通托酸。從細(xì)的方面講，所有的業(yè)務(wù)邏輯都應(yīng)該放在這里柒巫。用戶對于view的任何操作的內(nèi)部表現(xiàn)為presenter去請求相關(guān)model作出處理励堡，然后使用model處理后的結(jié)果來反過來在更新View。
- View：僅僅負(fù)責(zé)展現(xiàn)數(shù)據(jù)堡掏，View不僅僅局限于Activity应结，F(xiàn)ragment，事實上所有用戶可見或可以交互的都能稱得上是View這層的范疇泉唁。
接下來講的幾點是關(guān)于MVP設(shè)計原則的
1. 徹底讓View變成一個任人擺布的傀儡吧鹅龄！
試著想一想，View沒有了任何的業(yè)務(wù)邏輯游两，全部都抽到presenter中之后砾层，View剩下的工作實際上只是展示數(shù)據(jù)而已，列表也好贱案，詳情也罷，空頁面也是如此止吐。而presenter中全部都是與View無關(guān)的一些復(fù)雜的數(shù)據(jù)處理邏輯宝踪，測試將不會依賴android ui framework，可測試性將大大提高碍扔，不是嗎剖膳？
2. presenter徹底與UI脫離瓢棒！
presenter并沒有必要知道android ui的存在，他只是負(fù)責(zé)數(shù)據(jù)處理邏輯而已，數(shù)據(jù)，本身應(yīng)該不依賴于UI而存在谐区，因此，當(dāng)你的presenter中存在activity，textview等這些鬼時凳兵，那么你是時候考慮，是否真的需要這些ui層面上的東西了企软。有人可能會問了庐扫，那假如需要context獲取pref呢？這個問題也的確很棘手仗哨，事實上也是有辦法規(guī)避的形庭，比如，拿pref的工作交給View去做吧厌漂。這里pref盡可能的封裝好萨醒，避免view中去寫邏輯操作pref。
3. 將View和presenter定義在一個contract中苇倡！
實際上你也可以不必這么做富纸，但是為什么這里要拿出來說，實際上也是因為遇到過問題的
public interface SearchRepositoriesContract {
interface View {
void addResults(List<Repository> repos);
void clearResults();
void showContentLoading();
void hideContentLoading();
void showListLoading();
void hideListLoading();
void showContentError();
void hideContentError();
void showListError();
void showEmptyResultsView();
void hideEmptyResultsView();
}
interface Presenter extends BasePresenter<View> {
void load();
void loadMore();
void queryChanged(String query);
void repositoryClick(Repository repo);
}
}
如果將View和presenter分開到單獨的文件中雏节，那么將會出現(xiàn)
public interface SearchView{
void addResults(List<Repository> repos);
void clearResults();
void showContentLoading();
void hideContentLoading();
void showListLoading();
void hideListLoading();
void showContentError();
void hideContentError();
void showListError();
void showEmptyResultsView();
void hideEmptyResultsView();
}
public interface SearchPresenter extends BasePresenter<View> {
void load();
void loadMore();
void queryChanged(String query);
void repositoryClick(Repository repo);
}
那么胜嗓，假如項目業(yè)務(wù)繁多，20個钩乍，30個..100個呢辞州？文件數(shù)也就隨之比寫到一個contract中多了不少。而且還有一個好處寥粹，一眼便知presenter有哪些邏輯变过，view有哪些呈現(xiàn)樣式。
4. 不要在presenter中去寫Activity方式的生命周期回調(diào)涝涤。
`onCreate(...), onStart(), onResume() ...`媚狰，我一直認(rèn)為這些并沒有什么鳥用，假如你實現(xiàn)的View不是一個Activity阔拳，二十一個ViewGoup呢崭孤，是不是還會出現(xiàn)一些ViewAttatch之類的詭異接口來，而且
public interface BasePresenter<V> {
void attach(V view);
void detach();
}
這種方式不是更加直接嗎糊肠？在view需要用到presenter時attached辨宠，在view不可用時detach，我沒有想出這哪里不夠用的了货裹。
5. view的狀態(tài)應(yīng)該有model來持久化嗤形，并非是presenter
repository.get(params)這樣的一個操作封裝在model層即可，如果view數(shù)據(jù)已經(jīng)緩存弧圆，直接讀取即可赋兵，如果沒有笔咽，在從api拉取，presenter真心不應(yīng)該去做頁面狀態(tài)恢復(fù)的工作霹期。
