第一篇文章的结尾对时尚版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层进行了优化,实际开发中已经能发挥很大的做用。
下面一章旗舰版将三层同时优化。