基本上所有app的本质说到底都是从网络上获取数据， 然后在View上显示给用户.
下面这张图是一个概括性的对比架构图:
MVC 架构的代码
现在大多数的app架构采用的是MVC架构， Model(数据)， View, Controler.
android的Activity在MVC架构上就充当了Controler的角色, 但作为用户界面， 一定程度上也具有一定的View的角色.
MVC的开发模式， 典型的代码结构是在Activity类中调用model层来加载网络数据， 然后把原数据进行加工处理， 接下来设置给适当的View展示给用户。
这种模式下， 会出现2个问题.
一是， 会导致Activity类的代码多于庞大， 经常出现上千行的代码, 代码分析起来过于复杂. Activity作为Controler, 又作为View, 承担了过多的职责， 违背了"单一职责"的设计原则.
二是， 把Activity作为View来看， View和Model数据之间相互引用， 耦合性强, 无法实现2个模块间的解藕.
MVP 架构的代码
Model --- View --- Presenter
在MVP架构下， android的Activity类就只单纯的承担View的角色， 在Activity类中不做任何的数据处理, 当然也没有model数据层的引用, 只负责展示UI的工作. 职能单一， 符合"单一职责"的设计原则.
Activity对外提供的功能通过一个IActivity接口声明, Activity和Presenter之间相互引用. Activity直接引用Presenter的对象, Presenter中以IActivity接口的形式引用Activity的对象.
在Presenter中引用Model的对象， 执行数据的访问.
通过以上的架构可以看到， 作为单纯View角色的Activity和Model之间不存在引用关系, 两者实现了解藕. 更关键的是Activity只负责展示UI的工作， 代码简洁， 不会再出现上千行代码的情况.
此外， 把Acitivity抽象为某个接口还有一个好处是， 这个Activity能做哪些ui操作就一目了然了.
一个最简单的辨别方法
拿到一份新代码， 如果Activity类的代码行数超过几百行， 那基本就是采用传统上的MVC架构， 如果Activity的代码很简洁， Activity实现了一个接口， 接口里面定义了UI操作的一组方法，Activity类的大部分代码都是实现这个接口中声明的方法, 那基本上就是采用的MVP架构.
MVP 框架
主流框架: theMVP， beam
重要的是理解MVP的架构思想，在theMVP框架下， Activity充当Presenter的角色， ViewDelegate充当View层的角色. Model还是固定不变的数据层.
MVP 框架的核心思想是:
- View层和Model数据层不存在相互引用的关系.
- MVP把Activity中UI逻辑抽象成View接口， 把业务逻辑抽象成Presenter接口, Model层还是原来的数据层.
典型案例
使用ListView 显示一组数据
下面截取了几张讲座的关键截图
refer to:
动脑学院 架构设计 MVP 视频
------DONE.--------
