Android MVP系列（五）之MVC演变MVP就是那么简单？

快速回顾

上一章(Android MVP系列（四）之MVC下篇)我们已经组装了一个完整的MVC架构，我们可以看一下MVC框架的流程图：

       当然这张图只是说明了上一章新增的功能：下拉刷新 的流程图。可以看出Module层和View层之间是没有交互，让Controller层去沟通传递数据，这样看起来就和MVP的原理一样，但是这还是有点差异的，什么样的差异我们之后来讲。
       另外还有个需求是进入界面初始化列表数据，这个需求是Module层和View层直接沟通，这个和MVC的架构是相符合：Controller层只是负责转调Module去请求数据，而Module层请求完数据之后直接沟通View来获取数据，更新列表。

MVC过度到MVP

上一章场景

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

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

       租客（View）只和中介（Presenter）联系，房东（Module）也只和中介联系（Presenter）；假如中介换人了，按照之前的结构不需要任何改变，复用性强；现在房东只管收钱就好了，其他的事情都由中介处理，租客交租金、修电器、出现的等等问题，直接和中介沟通解决，等于可扩展性也强。

这个图我相信大家看着应该非常的眼熟了，这个和MVP的图已经完全符合了；

我们MVP中的Presenter的功能和场景中的中介者有着异曲同工之妙，他们的功能都是起到了隔离View（租客）和 Module (房东)的作用。

我们用一个完整的图来显示从MVC演变到MVP：

这里我们假设MVC架构为场景一、MVP架构为场景二；那么场景一和场景二的区别在哪儿呢？

区别：中介功能变化

场景一：中介负责处理流程的控制，功能单一。相当于说租客询问中介你那边有房源么？我需要租个什么样的房子，中介筛选租客需求之后，锁定了一个房东有这样的房源，然后给房东说有人要租你的房子