从字面意思来理解，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 设计模式：
1、View 层比较简单明，就是 View 的一些封装、重用。在一款精心设计过的 App 里面，应该有很多 View 是可以封装重用的。比如一些自己的 TableViewCell，自己设计的 Button，一些 View（包含一些子 View，UI 精心设计过，在项目里多处出现的）等等。
2、Model 层应该不仅仅是创建一个数据对象，还应该包含网络请求，以及数据 SQLite 的 CRUD 操作（比如 iOS 平台，一般以 FMDB 框架直接操作 sql，或者用 CoreData) 。一般可以将数据对象是否需要缓存设计成一个字段 isCache，或者针对整个项目设计一个开存储关，决定整个项目是否需要数据缓存。我们常见的新闻类 App，在离线的时候看到的数据，都是做了缓存处理的。比如一些金融类的 App，实时性比较高，是不做缓存的。
3、Presenter 层并不涉及数据对象的网络请求和 SQLite 操作，只是 Model 层和 View 层的一个桥梁。Presenter 层就不至于太臃肿，容易看懂。一些大的 App，或因为上线时间比较久了，经历过众多程序员的修补，或因前期并未做好架构，以至于打开一个类，几千行的代码，看着自己都晕。
