第一篇文章的結尾對時尚版MVP結構作了一個簡單的預告,下面繼續從時尚版MVP提及。數組
在從乞丐版MVP架構優化成平民版MVP架構的過程當中,幾乎每一個單元都作了很大優化並封裝到了base層,可是惟獨Model層沒什麼變化。因此,時尚版MVP架構的優化主要就是對Model層的優化。bash
Model層相比其餘單元來講比較特殊,由於它們更像一個總體,只是單純的幫上層拿數據而已。再就是MVP的理念是讓業務邏輯互相獨立,這就致使每一個的網絡請求也被獨立成了單個Model,這種方式在實際開發中就會出現一些問題:網絡
因此咱們更但願Model層是一個龐大且獨立單一模塊,請求方式規範化,管理Model更加直觀。架構
如上圖所示,時尚版MVP架構的Model層中,Presenter 請求數據再也不直接調用具體的Model對象,統一以 DataModel
類做爲數據請求層的入口,以常量類 Token
區別具體請求。 DataModel會根據Token的不一樣拉取底層對應的具體Model。ide
優化以後的Model層是一個龐大並且獨立的模塊,對外提供統一的請求數據方法與請求規則,這樣作的好處有不少:post
根據上節結構圖中的描述在考慮到實際狀況,咱們須要設計如下幾個類:測試
DataModel
: 數據層頂級入口,項目中全部數據都由該類流入和流出,負責分發全部的請求數據。Token
:數據請求標識類,定義了項目中全部的數據請求。BaseModel
:全部Model的頂級父類,負責對外提供數據請求標準,對內爲全部Model提供請求的底層支持。最後實現後理想的請求數據方法是:優化
BaseModel中定義了對外的請求數據規則,包括設置參數的方法和設置Callback的方法,還能夠定義一些通用的數據請求方法,好比說網絡請求的Get和Post方法。ui
public abstract class BaseModel<T> {
//數據請求參數
protected String[] mParams;
/**
* 設置數據請求參數
* @param args 參數數組
*/
public BaseModel params(String... args){
mParams = args;
return this;
}
// 添加Callback並執行數據請求
// 具體的數據請求由子類實現
public abstract void execute(Callback<T> callback);
// 執行Get網絡請求,此類看需求由本身選擇寫與不寫
protected void requestGetAPI(String url,Callback<T> callback){
//這裏寫具體的網絡請求
}
// 執行Post網絡請求,此類看需求由本身選擇寫與不寫
protected void requestPostAPI(String url, Map params,Callback<T> callback){
//這裏寫具體的網絡請求
}
}
複製代碼
寫好了BaseModel後再看實現具體Model的方法:this
public class UserDataModel extends BaseModel<String> {
@Override
public void execute(final Callback<String> callback) {
// 模擬網絡請求耗時操做
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
// mParams 是從父類獲得的請求參數
switch (mParams[0]){
case "normal":
callback.onSuccess("根據參數"+mParams[0]+"的請求網絡數據成功");
break;
case "failure":
callback.onFailure("請求失敗:參數有誤");
break;
case "error":
callback.onError();
break;
}
callback.onComplete();
}
},2000);
}
}
複製代碼
從上面代碼段能夠看出,實現具體的Model請求時必需要重寫BaseModel的抽象方法execute
。
因爲DataModel負責數據請求的分發,因此最初打算做成一個簡單工廠模式的樣子,經過switch(token)
語句判斷要調用的Model。
但若是這樣設計的話,在實際開發中咱們每次添加一個數據請求接口,不光須要新建對應的Model和Token,還須要在DataModel類的switch(token)
語句中新增長對應的判斷,賊麻煩~
思來想去,我以爲利用反射機制會是一個比較理想的辦法,請求數據時以具體Model的包名+類型做爲Token,利用反射機制直接找到對應的Model。
public class DataModel {
public static BaseModel request(String token){
// 聲明一個空的BaseModel
BaseModel model = null;
try {
//利用反射機制得到對應Model對象的引用
model = (BaseModel)Class.forName(token).newInstance();
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return model;
}
}
複製代碼
因爲上節中DataModel使用反射機制獲取對應Model的引用,因此Token中存的就應該是對應Model的包名+類名:
public class Token {
// 包名
private static final String PACKAGE_NAME = "com.jesse.mvp.data.model.";
// 具體Model
public static final String API_USER_DATA = PACKAGE_NAME + "UserDataModel";
}
複製代碼
完成了Model層以後再去Presenter調用數據時的樣子就舒服多了:
DataModel
// 設置請求標識token
.request(Token.API_USER_DATA)
// 添加請求參數,沒有則不添加
.params(userId)
// 註冊監聽回調
.execute(new Callback<String>() {
@Override
public void onSuccess(String data) {
//調用view接口顯示數據
mView.showData(data);
}
@Override
public void onFailure(String msg) {
//調用view接口提示失敗信息
mView.showFailureMessage(msg);
}
@Override
public void onError() {
//調用view接口提示請求異常
mView.showErrorMessage();
}
@Override
public void onComplete() {
// 隱藏正在加載進度條
mView.hideLoading();
}
});
複製代碼
通過優化的Model層很好的統一化了請求方法規範,利用BaseModel不只有效的減小了數據請求的冗餘代碼,最關鍵的仍是獲得了將全部Model的集中控制權,例如咱們想給全部的請求都加上coockies,直接在BaseModel層作處理便可。
時尚版MVP雖然只對Model層進行了優化,實際開發中已經能發揮很大的做用。
下面一章旗艦版將三層同時優化。