文档开发者中心
我的

Android MVP系列(四)之MVC下篇

题外话

可能有人会说,你写个MVP,为啥用了前面三篇(Android MVP系列(一)、Android MVP系列(二)之MVC结构、Android MVP系列(三)之MVC中篇)加上本篇来叙述MVC,我花这么几个章节来详细解释MVC,就是为了让我们能更加容易理解、掌握MVP的框架,通过MVC来平滑过渡到MVP,让读者能更加的自然的接受,不至于突兀,有点不知所措。如果还没有阅读过之前章节的同学,不妨花点时间耐心看看之前的章节,MVC和MVP是有很多共性的。


1

为MVC赋予灵动的生命


沟通机制

上一章我们最后搭建了一个MVC框架的雏形,但是在文末的时候我提出说:这个框架看起来比较死板、灵活性不强,感觉哪里怪怪的,缺少点生命灵性。

这就是我这个章节要重点讲解的:沟通机制。看上一章我们搭建的框架,没有哪个地方有沟通机制,所以看起来比较死板。

JAVA里面有一种设计模式叫观察者模式,那么这里就是我要说的沟通机制;如果不清楚的也没关系,我会一步一步的讲解。


观察者模式也叫:发布-订阅模式。


观察者模式的主要两个人物:

Observer(观察者)、Obserable(被观察者)


整个事件的驱动过程:

订阅(Subcribe)、发送事件、接收事件、处理事件


那我们已经清楚观察者模式的基本结构,那么我们将观察者模式应用到我们的MVC框架中,让框架赋予灵性。


场景

在之前的MVC框架上,我们增加需求:


给列表增加刷新功能


MVC框架添加监听机制满足功能需求

第一步、创建观察者

首先我们想想需求,我们是要刷新列表,我们需要观察者观察什么呢?这个需求当中最主要的就是刷新数据,也就是说最重要的就是数据是否刷新完成是一个点,这个点就是我们要观察的目标。所以我们的观察者就需要具备数据是否刷新完成的能力


按照上面的推理步骤我们可以写出一个观察者接口:

/**我是一个“观察者”**/
public interface Observer {
/**监听数据刷新完成**/
void onRefreshFinish(List<NewsBean> data);
}


这就是我们的观察者了,但是我们还没写到MVC框架里面让谁有这个观察者能力呢?这里我们就需要明白MVC框架的分层理解了,回顾一下:

Module层职责


Module层数据模型层,对业务逻辑的处理,数据库、网络、算法等。



View层职责

1.呈现M层的数据

2.主动询问或者被动监听(例如:下拉刷新列表主动询问)

3.通知C层处理

4.接收C层,改变UI


Controller层职责

接收V层的操控,并转调给M层来改变V层UI或者状态


按照功能来区分的话,我们看得出只有Controller层最合适,由于它主要是接收View的控制,转调Module去服务器刷新数据,再来改变View刷新列表。


因此我们赋予Controller观察者的能力:


/**我是一个Contorller,同时我就是观察者**/
public class Controller implements Observer{
/**接收事件**/
@Override
void onRefreshFinish(List<NewsBean> data){
//处理事件
}
...
...
...
}


第二步、创建被观察者、并订阅

这里毫无疑问就是Module层是被观察者,Module去订阅

/**这是一个Model**/
public class Module{
private IView view;
private Observer observer;

//构造方法传入View
public void Module(IView view){
this.view=view;
}
//订阅观察者
public void addObserver(Observer observer){
this.observer=observer;
}
//从服务器请求获取新闻列表数据
void getNewsData(boolean flag) {
//耗时获取数据
...
//将服务器返回的List<NewsBean>集合dataList保存到本地
this.saveCacheNews(dataList,flag);
}
//保存新闻列表到内存中
void saveCacheNews(Lis<NewsBean> dataList,boolean flag){
//保存到本地
...
//判断下刷新还是初始化
if(flag){
//发送事件
observer.onRefreshFinish(dataList);
}else{
//通知view 刷新列表了
view.updateView();
}

}
//从内存缓存获取数据
NewsBean getNewsCache() {
//内存中去获取数据 datas
...
return datas;
}
}

第三步、订阅者接收事件

/**这是一个Contorller**/
public class Controller implements Observer{
private IView view;
private Module module;
//构造方法注入View
public void Controller(IView view){
this.view=view;
}
//注入Module
public void Controller(Module module){
this.module=module;
}
//转调Module加载数据
void loadNewsList(boolean flag) {
//做个判断是刷新还是初始化
if(flag){
module.getNewsData(false);
view.showLoading();
}else{
if(module.getNewsCache() == null){
//执行Modle
module.getNewsData(false);
//执行View开始加载数据了,显示加载动画
view.showLoading();
}
}
}
/**接收事件**/
@Override
public void onRefreshFinish(List<NewsBean> datas){
//处理事件 onDataBack哪儿来的,我们处理view的时候说明
view.onDataBack(datas);
}
}

最后一步,我们View中怎么处理事件的呢?

我们现在的框架算是比较完整了,

public class MainActivity extends AppCompatActivity implments IView{
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//初始化Controller,this就是View,通过构造器注入
Controller controller = new Controller(this);

//初始化Model,Model -> View and View -> Model
Module model = new Module(this);
//module注入到Controller
controller.setModule(module);
//Controller -> Model 这个地方就是我们的订阅事件了 controller是Observer的实现类
model.addObserver(controller);
//初始化,让Controller转调Module请求数据
this.viewInit(false);
}
@Override
public void updateView(){
//主动请求Model获取数据
NewsBean data = module.getNewsCache();
//更新ui
list.update(data);
//隐藏loading界面
this.hideLoading()
}
@Override
public void showLoading(){
list.showLoading()
}
@Override
public void hideLoading(){
list.hideLoading
}
//刷新界面数据了,通知Controller
//flag 表示判断是初始化界面还是刷新数据 false 初始化 true 刷新
public void viewInit(boolean flag){
controller.loadNewsList(flag);
}
//相当于我们的下拉刷新列表的时候,activity中调用onRefresh方法
pulic void onRefresh(){
controller.loadNewsList(true);
}
//Controller层接收事件之后,控制View处理事件,刷新界面
public void onDataBack(List<NewsBean> datas){
list.update(datas);
this.hideLoading
}

}


这样我们的MVC的框架就算是比较完整了;

View层:触发刷新、接收数据、更新UI界面,数据怎么来的一概不管。

Contronller层:接收View控制、转调Module层请求数据、控制View的状态、监听刷新数据完成。

Module层:处理数据、请求数据。

各个层的职责非常清楚、便于维护、逻辑清晰等优点。


总结

在MVC这个模式中,我们建立的沟通机制,是最常见的方式。但是我们很多人一眼看的出来,在View层中既有Module对象,又有Controller对象,Controller层中也有Module对象,Module层中又含有Controller对象,这样复杂的对象引用关系,估计很多人都晕了。

而且这种复杂的引用关系,不利于管理,可扩展性也差,所以这才有了我们MVP的框架,MVP有两个非常重要的能力:复用性和可扩展性,还有就是解决对象的复杂引用关系、便于维护。


2

引出MVP
新的场景

我们都是上班族,毕竟面临租房子的问题,那么我们经常租房子肯定是找中介。现在我们就有三个人物:租客、中介、房东三个人物

这个图和我们的MVC的图片貌似神似啊(原谅我画的有点丑),但是这个场景就和我们的MVC非常符合,但是现在新的需求改变了:


由于房东比较忙,他给中介说,我比较忙我不想和租客去沟通价格、修理家具。。。等等很多的事情,你都给我办了,包括租金,租约你都处理了,我就收钱就好了,其他的我不管。现在的图形就演变成下面这样了:

当然这个图里面付钱,签合同等都是中介完成,就没有画出来了,但是我们可以清楚的看到房东和租客没有任何联系了,一切事情找中介就好了。那么这张图和我们的MVP的经典图片又有什么区别呢?


这种模式下人员关系方面简单得多,这里我们把:


租客==View、中介==Presenter、房东==Module


现在的关系非常清楚,租客(View)只和中介(Presenter)联系,房东(Module)也只和中介联系(Presenter);假如中介换人了,按照之前的结构不需要任何改变,复用性强;现在房东只管收钱就好了,其他的事情都由中介处理,租客交租金、修电器、出现的等等问题,直接和中介沟通解决,等于可扩展性也强,最终知会一下房东就好。不知道这样解释清不清楚,假设如果还是理解不清楚,没关系,下一章节我们用代码的形式展示就会很清楚了


那就期待一下章节的从MVC平滑过渡到MVP,让你轻松掌握MVP。


点赞
收藏
回复
分享
举报
浏览792 发布于2019-08-27 08:55未知归属地
全部评论
最多点赞
最新发布
最早发布
暂无评论
暂无评论
写回答
新增插入模板功能
一键使用模板,快速填写内容,轻松发帖~
知道了
  • 为了保障您的信息安全,请勿上传您的敏感个人信息(如您的密码等信息)和您的敏感资产信息(如关键源代码、签名私钥、调试安装包、业务日志等信息),且您需自行承担由此产生的信息泄露等安全风险。
  • 如您发布的内容为转载内容,请注明内容来源。

我要发帖子

了解社区公约,与您携手共创和谐专业的开发者社区。