排版不佳建议查看原文
浅谈MVC
在我待过的小公司中，大多数Android项目依然使用的还是MVC架构，因为它相对简单，项目搭建初期，我们可以不用花费太多精力便可以搭建出项目框架，快速投入业务代码的开发中。随着时间的推移，业务的增加，代码层次越来越不清晰，甚至会出现一个Activity超过两千行的情况，包含了操作网络的回调函数、解析数据的函数、本地存储的函数、以及操作UI的函数。随之而来更难调试的bug、内存泄漏等等问题。相信你一定看见过。在我看来这种项目连MVC架构都不是！我们就叫它VC架构好了。
我项目中的MVP
由于曾经就职某小外包公司的缘故，平均每隔1个月我就会从0开启一个新项目，所以我开始尝试MVP、甚至是MVVM架构。
总体来说，我的目的是使得项目层次更清楚，在View层抽离一切于UI操作无关的任务，移植到Model层独立，并且中间新增Presenter关联View与Model层。
View层
第一步是建立View接口，目的是定义我们的页面有哪些公共的UI行为，可见图上showLoading函数与hideLoading函数定义为我们页面加载数据时操作进度条的函数。showError函数为加载数据失败情况UI的操作函数。onSuccess为加载数据成功的操作函数，UI可直接获取形参中的数据包显示操作。isActive代表当前页面是否可见。以上统称为View接口，由View（Activity、fragment）实现。
第二步建立Contract接口，你可能会问Contract是什么，由于我们定义了BaseView接口抽离了View的公共UI行为，可是每个页面都可能有自己的UI行为，所以BaseView接口只能是基类，由每个页面的View接口去继承它，如图下的LoginView接口。那么一个页面将要新建一个View接口文件，会非常多，所以我们将所有View接口写到了Contract接口内部，Contract可以理解为一个装载接口的容器。
第三步，创建View接口的实现类LoginActivity！
图上，我们实现了LoginView接口的所有函数，如showLoading我们只需要显示progressDialog，无需关心何时调用，只关心函数需要实现的UI操作即可，职责单一。
Model层
有了View层，下面实现Model层。
第一步，历史总是惊人相似，图上定义LoadTasksCallBack接口与BaseView接口十分相似，目的是定义我们数据请求的4种基本状态，onSuccess加载成功、onStart开始加载、onFailed加载失败、onFinish加载结束。
第二步，图上定义BaseNetTask接口，目的是让负责逻辑代码的Model层拥有执行任务的函数execute。我们发现其形参中携带了我们上面定义的LoadTasksCallBack，目的是让execute函数开始执行或完成后通过其形参LoadTasksCallBack接口回调其执行结果给LoadTasksCallBack接口的实现类。从而实现与Presenter层通信。
第三步，与View层的BaseView类似，我们的BaseNetTask仅仅只是定义了一个基本的执行任务的函数execute，也许一个页面并不只有一次或者一种逻辑任务需要处理，这时候execute显得不够了，所以BaseNetTask仅仅作为基类，如图上的LoginNetTask在BaseNetTask基础上扩展了自己的任务函数getTime。最后同样定义在Contract内部。
第四步，创建实现LoginNetTask接口的实现类LoginTask。如图上红色框框标注位置，我们实现了execute函数与getTime函数，同样是职责单一，不关心谁会调用，仅仅关注内部实现，execute中我们完成了登陆的逻辑，并且通过LoadTasksCallBack接口成功将结果回调。这样实现LoadTasksCallBack接口的实现类则会收到此次任务的结果。
还有值得注意的是，Task相关的类都采用单例模式。
Presenter层
经历了View层与Model层，你会发现它们都是相对独立的模块，各自并不直接联系。所以我们需要创建BasePresenter如图下：
第一步，我们实现了LoadTasksCallBack接口，在Model层我们知道LoadTasksCallBack接口主要让Model层execute函数开始执行或完成后通过其形参LoadTasksCallBack接口回调其执行结果给LoadTasksCallBack接口的实现类。没错，就是这里，Model层的任务执行结果都来到这。
在构造函数中我们发现，BasePresenter需要接收BaseView接口的实现类与BaseNetTask接口实现类才可被实例化。换句话说，创建BasePresenter需要传Activity||fragment与LoginTask。
由于LoginTask所有任务的结果都会传递到BasePresenter，所以在onSuccess中，我们判断页面是否可见，然后隐藏进度条，再转发数据到View层的onSucess中。目的就是Presenter收到Model层的结果回调后，再根据响应状态回调View层UI操作函数。其余函数职责相同。
第二步，图上你可能会问，咋又是BasePresenter，它们还真不一样，定义BasePresenter接口，目的是提供View层去调用加载数据函数的一个入口，如Activity通过startExecute方法开启一个加载数据的任务，具体往下看：
一样的目的，因为BasePresenter接口只定义一个提供给View层操作的基本加载数据的函数入口，所以只能定义为基类，每个页面可以自定义增加提供给View触发，加载数据的函数。如上图LoginPresenter，由于LoginNetTask提供getTime函数，如果View层需要触发getTime，则需要在LoginPresenter相应增加getTime函数。
第四步，图上创建LoginPresenter类继承BasePresenter，实现LoginPresenter接口。是不是信息量有点大？首先继承BasePresenter类，这样Model层的结果回掉统统都在基类中处理完毕，派生类只关心View层的任务。
然后实现LoginPresenter接口，startExecute函数与getTime函数职责就是接受View层的调用，其内部再去转发调用Model层的execute与geiTime函数触发数据操作，起到了中介的作用。
最后：在View层的Activity初始化时候，我们仅仅只需要实例化Presenter，通过Presenter我们可以调用任意Model层的函数，并且最终Activity-onSuccess中只获取加载处理完毕的数据直接更新UI，并不关心其内部实现。
总结
问题
onSccess函数每个页面只有一个，只能实现一次。由于onSccess函数承担了所有的数据请求结果的接收，假设一个页面有多种多个不同的数据请求结果，则在onSccess（Object data）,data中无法区分数据造成严重问题。小编也是非常苦恼。后来将函数形参修改成onSccess(Object data,int Type),新增了Type，在Model层加以Type区分，则在View层根据Type分别更新UI。
这可能不是最佳解决方案，如果你知道可以给我留言，谢谢支持。
欢迎长按下图-识别图中二维码或者扫一扫，搜索微信公众号：黄君华。关注我的公众号：
如果你有不同意见或建议或者有好的技术文章想和大家分享欢迎投稿，可以把你的文章使用附件的形式发送到我的邮箱[email protected] 谢谢阅读！