Android MVP系列（四）之完整MVC

今天这篇文章主要分为两大部分：

一、为上一章的MVC赋予灵动的生命；
二、指出MVC的不足和引出MVP的优点；

题外话

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

第一部分：为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有两个非常重要的能力：复用性和可扩展性，还有就是解决对象的复杂引用关系、便于维护。

第二部分引出MVP

新的场景

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

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

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

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

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

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

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

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

---

原创不易，如果觉得写得好，扫码关注一下点个赞，是我最大的动力。

关注我，一定会有意想不到的东西等着你：
每天专注分享Android、JAVA干货

备注：程序圈LT
微信扫一扫
关注该公众号