iOS - MVP 架构模式

一、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 和 Model，而 View 的功能较少；
  • 可测试性 -- 很是好，因为一个功能简单的 View 层，因此测试大多数业务逻辑也变得简单；
  • 易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却很是清晰。

• 2）iOS MVP 示意图：

  • 就 MVP 而言，UIViewController 的子类实际上就是 Views 并非 Presenters。这点区别使得这种模式的可测试性获得了极大的提升，付出的代价是开发速度的一些下降，由于必需要作一些手动的数据和事件绑定。

  • 还有一些其余形态的 MVP -- 监控控制器的 MVP。这个变体包含了 View 和 Model 之间的直接绑定，可是 Presenter 仍然来管理来自 View 的动做事件，同时也能胜任对 View 的更新。

• 3）规范的 MVP 设计模式：

  • 一、View 层比较简单明，就是 View 的一些封装、重用。在一款精心设计过的 App 里面，应该有不少 View 是能够封装重用的。好比一些本身的 TableViewCell，本身设计的 Button，一些 View（包含一些子 View，UI 精心设计过，在项目里多处出现的）等等。

  • 二、Model 层应该不单单是建立一个数据对象，还应该包含网络请求，以及数据 SQLite 的 CRUD 操做（好比 iOS 平台，通常以 FMDB 框架直接操做 sql，或者用 CoreData) 。通常能够将数据对象是否须要缓存设计成一个字段 isCache，或者针对整个项目设计一个开存储关，决定整个项目是否须要数据缓存。咱们常见的新闻类 App，在离线的时候看到的数据，都是作了缓存处理的。好比一些金融类的 App，实时性比较高，是不作缓存的。

  • 三、Presenter 层并不涉及数据对象的网络请求和 SQLite 操做，只是 Model 层和 View 层的一个桥梁。Presenter 层就不至于太臃肿，容易看懂。一些大的 App，或由于上线时间比较久了，经历过众多程序员的修补，或因前期并未作好架构，以致于打开一个类，几千行的代码，看着本身都晕。