###解释

  • 从字面意思来理解，MVP即Modal View Presenter（模型 视图 协调器），MVP实现了Cocoa的MVC的愿景。MVP的协调器Presenter并没有对ViewController的声明周期做任何改变，因此View可以很容易的被模拟出来。在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。
  • MVP 是第一个如何协调整合三个实际上分离的层次的架构模式，既然我们不希望 View 涉及到 Model，那么在显示的 View Controller（其实就是 View）中处理这种协调的逻辑就是不正确的，因此我们需要在其他地方来做这些事情。例如，我们可以做基于整个 App 范围内的路由服务，由它来负责执行协调任务，以及 View 到 View 的展示。这个出现并且必须处理的问题不仅仅是在 MVP 模式中，同时也存在于以下集中方案中。

MVC和MVP的区别就是，在MVP中M和V没有直接通信。

MVP模式下的三个特性的分析

  • 任务均摊 -- 我们将最主要的任务划分到 Presenter 和 Model，而 View 的功能较少；
  • 可测试性 -- 非常好，由于一个功能简单的 View 层，所以测试大多数业务逻辑也变得简单；
  • 易用性 -- 代码量比 MVC 模式的大，但同时 MVP 的概念却非常清晰。

iOS MVP 示意图

iOS中MVP模式 ios mvp_数据库

  • 就 MVP 而言，UIViewController 的子类实际上就是 Views 并不是 Presenters。这点区别使得这种模式的可测试性得到了极大的提高，付出的代价是开发速度的一些降低，因为必须要做一些手动的数据和事件绑定。
  • 还有一些其他形态的 MVP -- 监控控制器的 MVP。这个变体包含了 View 和 Model 之间的直接绑定，但是 Presenter 仍然来管理来自 View 的动作事件，同时也能胜任对 View 的更新。

规范的MVP设计模式

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

2、View 层比较简单明，就是 View 的一些封装、重用。在一款精心设计过的 App 里面，应该有很多 View 是可以封装重用的。比如一些自己的 TableViewCell，自己设计的 Button，一些 View（包含一些子 View，UI 精心设计过，在项目里多处出现的）等等。

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

MVP的优势

  • 模型与视图完全分离，我们可以修改视图而不影响模型
  • 可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部
  • 我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
  • 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

MVP的问题

  • 由于对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁.
  • 还有一点你需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的 联系过于紧密。一旦视图需要变更，那么 Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。