MVP概括

  • 从字面意思来理解，MVP 即 Modal View Presenter（模型 视图 协调器），MVP 实现了 Cocoa 的 MVC 的愿景。MVP 的协调器 Presenter 并没有对 ViewController 的生命周期做任何改变，因此 View 可以很容易的被模拟出来。在 Presenter 中根本没有和布局有关的代码，但是它却负责更新 View 的数据和状态。MVC 和 MVP 的区别就是，在 MVP 中 M 和 V 没有直接通信。
  • MVP 是第一个如何协调整合三个实际上分离的层次的架构模式，既然我们不希望 View 涉及到 Model，那么在显示的 View Controller（其实就是 View）中处理这种协调的逻辑就是不正确的，因此我们需要在其他地方来做这些事情。例如，我们可以做基于整个 App 范围内的路由服务，由它来负责执行协调任务，以及 View 到 View 的展示。这个出现并且必须处理的问题不仅仅是在 MVP 模式中，同时也存在于以下集中方案中。
  • 1）MVP模式下的三个特性的分析：
  • 任务均摊 -- 我们将最主要的任务划分到 Presenter ，而 View 的功能较少；
  • 可测试性 -- 非常好，由于一个功能简单的 View 层，所以测试大多数业务逻辑也变得简单；
  • 易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却非常清晰。
  • 2）iOS MVP 示意图：

 

View|Presenter的交互上面，就是说：View单纯地将用户的交互请求汇报给Presenter；Presenter接收到请求之后，整合相应的资源、执行相应的处理逻辑。对处理流程的某一个步骤，如果设置到业务逻辑和数据模型，则调用Model，如果涉及到对GUI控件的操作，还会调用View。View将交互请求递交给Presenter之后，不需要考虑后续需要做什么，因为Presenter会在适当的时候命令View该如何做

 

 

MVP为了解决GUI开发过程中代码组织和职责规划的问题才总结出来的一套开发方法. MVP解决的只是”用户交互”-“数据处理”-“界面更新”这三者之间的问题.

  • Model: 数据层, 从本地数据库或者服务器获取并处理数据, 然后将数据反馈给presenter;
  • Presenter: 业务处理层, 接收处理View传递过来的用户交互事件, 从Model层获取数据后进行业务逻辑处理, 然后更新View;
  • View: 展示层, 将所有的交互事件传递给presenter处理, 自身只提供更新数据的接口(对iOS来说, ViewController显示也属于View层).

整个交互流程看起来大致是这样的:

用户交互->View获得交互事件->View将事件转发给Presenter->Presenter调用Model获取新数据->Presenter将数据推送给View进行展示