安卓中MVC模式的深度思索和实践(三)
这是一个有关安卓MVC框架模式的短系列，目的是思索和分析安卓中MVC模式更为真实的一面。
系列：
在上一篇中，主要通过一个demo项目，介绍了控制器的优化，简单回顾下：控制器C，或者叫做调度器，主要用来委托操作和调度，它不应该着眼于业务逻辑或者视图逻辑；而要将业务逻辑和视图逻辑，都还给对应的V层和M层。视图业务逻辑，可视情况委托给业务工具类（Helper）。对于调度职责来说，要构建一个调度体系，上级调度管理下层调度，下层调度管理下下层调度，整体就是采用分而治之的思想，实现页面级别的模块化。
在本篇文章中，主要是针对Model层进行一些探索，根据本系列第一篇中所述数据M，具备数据存取和操作职责，职责的划分是通过是否要与V发生联系来进行的。比如对于C来说，M应该就是一个最终且最有目的性的需求品，C不该关心这个目标数据怎么来的。这使得一般的校验和缓存等操作，应该存在于M层。
在某种程度上来说，MVP中的P层也承担了本文中提到的M层的一些职责。比如从获取远程数据，然后会对数据进行一步步的校验、过滤、解析和缓存等操作，最后通过接口，回调给UI层的对应方法。
本系列是来探索MVC的，而且前面也说了MVX的核心都在分层，表现在职责单一和清晰化。数据层M应该具有其对应的数据存取和操作职责，其中操作将会包括校验，过滤等过程。对于一般见到的M层，一般表现为JavaBean，不过这种类，应该是最基础的数据模型，只是在类内部层面上具有数据的存取操作，而对于M层来说，需要一种对象，来承担数据操作的过程。这里，作者引入了Action对象，其主要承担的职责便是请求网络数据，配置网络请求，校验数据，缓存数据，即承担了M层本该承担的职责。理论总是枯燥的，还是上些代码来解释下。这里我想通过项目中使用的一个小的开源库来介绍一下M层的分离和清晰化。
项目地址：https://github.com/Cysion1989/ModelAction
下面大概的讲解下本库的sample中的一些代码，由此来梳理M层。
- Controller中有关M的调用
GetAction mGetAction = new GetAction(this);
mGetmGetAction.taskId(GetAction.ZHIHU_DATE).path("20170503").execute(DataState.NO_CACHE);
-构造方法里是回调接口，taskid是请求跟踪标志，path是补充路径，DataState是缓存操作码，这里代表不缓存；
PostAction mPostAction = new PostAction(this);
mPostAction.taskId(PostAction.POST01).params(param).execute(DataState.CACHE_FIRST);
- params是请求传参，DataState是缓存操作码，这里代表优先使用缓存，缓存没有，才请求网络；
- 然后看一个实际子action中的操作
public class PostAction extends BaseAction {
public static final int POST01 = 200;
public static final int POST02 = 201;
public PostAction(TActionListener aListener) {
super(aListener);
}
@Override
protected String getUrl(int aTaskId) {
switch (aTaskId) {
case POST01:
return Urls.POST_ONE;
case POST02:
return Urls.POST_TWO;
}
return Urls.POST_ONE;
}
@Override
protected Method getHttpMethod(int aTaskId) {
return Method_POST;
}
@Override
protected boolean getTargetDataFromJson(String aResult, int aTaskId) {
if (aResult.length() > 100) {
listener.onSuccess(aResult.substring(0, 99), aTaskId);
return true;
} else if (aResult.length() > 30) {
listener.onSuccess(aResult.substring(0, 29), aTaskId);
return true;
}
return false;
}
}
在action中，getUrl(int aTaskId)是根据taskId确定了url，然后getHttpMethod确定了请求方法，然后请求是通过基类MvcAction中的execute来进行参数校验、缓存配置和数据请求操作：
public void execute(DataState actionCode) {
mActionCode = actionCode;
url = getUrl(taskId);
mReqMethod = getHttpMethod(taskId);
if (!TextUtils.isEmpty(mPath)) {
url += mPath;
mPath = null;
}
checkUrlAndId();
checkActionCode();
getKey();
if (!MvcUtils.isNetAvailable(mContext)) {
whenNoNet();
return;
}
if (mActionCode == DataState.CACHE_FIRST) {
if (!isCacheValid(taskId)) {
byHttp();
}
} else {
byHttp();
}
}
最后通过方法getTargetDataFromJson来处理获取的数据，数据结构是String类型，数据来源可能是网络，也可能是缓存，这个主要是根据controller中DateState来进行配置的，内部由MvcAction实现。通过层层校验后，调用 listener.onSuccess(result, taskId)来把目标数据回调会controller，需要注意的是，此处的数据是目标数据，即通过层层处理后，controller中最需要的数据，taskid是跟踪标志。
- 重回controller看回调数据
action内部数据回调接口主要有两个方法，见代码。
@Override
public void onSuccess(Object obj, int taskId) {
String result = (String) obj;
switch (taskId) {
case GetAction.ZHIHU_NEW:
mTextShow.setText("noCache---" + result);
break;
case GetAction.ZHIHU_DATE:
mTextShow.setText("path---" + result);
break;
case GetAction.WEATHER_ID:
mTextShow.setText("params---" + result);
break;
case PostAction.POST01:
mTextShow.setText("cache first---" + result);
break;
case PostAction.POST02:
mTextShow.setText("net first---" + result);
break;
case KeepTimeAction.GET_TIME:
mTextShow.setText("keep_time---" + result);
break;
}
}
@Override
public void onFailure(Object obj, int taskId) {
mTextShow.setText("failure");
}
最终，通过接口回调和跟踪标志，使得controller既不用考虑如何进行数据获取，也不用承担数据校验、解析、缓存等操作，而这些都是放到了上面介绍中的action对象中，action在这里，充当的是数据逻辑层，和javabean共同组成M层。
以上，就是一种对M层进行分层优化的思路，其实还是与MVP中的P层有相似之处的，只是P为了使M和V比较完全的解耦，便加入了多项业务的细分接口，而此处的M，并没有对业务接口进行细分，使得M和V并没有解耦太好，但从分层的角度来讲，这里的M是比较清晰的一层，是在常见MVC基础上，大粒度的一种解耦方式。
本系列到这里基本介绍完了，前面说了很多文字，可能阐述上不是那么明白。这里做个简单总结，并附上一个框架图来帮助我们理解。
MVC的核心，是在分层，分层的关键，来自于每层的的职责如何单一和清晰化。最后以一个页面级别的结构图，来阐述各层以及各层之间的关系，并作为本系列的结束。
页面级别的MVC结构图
篇幅较长，码字不易。
欢迎交流，共同进步!
