MVP架构模式

一、MVP模式图示

MVP 模式将 MVC中的controller 改名为 Presenter，同时改变了通信方向。

特点 :

(1)各部分之间的通信，都是双向的。

(2)View 与 Model 不发生联系，都通过 Presenter 传递。

(3) View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

M：model层

V:  视图层

P:  协议层（protocol）

二、MVP在iOS中的运用

首先，MVP基于面向协议(protocol)的设计模式。这就意味在工程里面，你需要定义多个协议文件，但是，我们都知道定制一个协议，可能会遵循一些属性或者可选实现必选实现的方法，当P层（controller）遵循这个协议，需要设置代理，由这个代理对象去实现被代理执行的工作。然而，在ios开发中，能用协议实现的，我们大部分都用块直接去回调执行，增强代码的可阅读性和紧凑性。

MVP模式的原则是，在service层提供一大堆不尽相同的业务场景之后，我们将这一系列数据全部抽象归纳，通过定制一套标准的protocol协议，让不同业务场景的都去实现这一协议，最终将数据全部装配、拼装成一套具有相同调度规则的统一编制话数据Model，之后我们采用id的标准去操作数据。

MVP除了将数据逻辑完全镇封的各自的Model,同时将那些Model需要绘制，哪些Model需要校验,

哪些Model需要接受处理点击Action这些逻辑全部由Model自己来决定，Controller只作为一个粘合性的模版，Controller只处理一批具有共性的范型类数据，至于具体的操作操作毫不关心。

MVP面相的更多的是在MVC上层与service之间追加了一层协议层，我们认为通过协议层处理过的数据是暂时可以客户端场景使用的数据，在数据到达MVC我们针对数据进行再加工、再构造处理，这一切全部在容器内操作。这一点完全与别的设计模式相反。

MVP并不是让用户在Model打上网络请求操作、在Model层执行[self.navigationController pushViewController:*]等这些操作，其实相对大多人来说对于部分对象生命周期长短问题还是很在乎，所以在处理TemplateActionProtocol协议的时间，MVP只是对准Action做了一层抽象封装。通过实现TemplateActionProtocol的Model会产生一个Action对象，最终通过block的调用链传回控制器中,我们在控制器中统一做handler处理。

MVP最初设计目的就是为了强调一个装配概念，如果发生了业务场景的追加,控制器我不会改动其中的代码，只需要将新数据追加成相同批次的ViewModel，然后配置进容器，之后控制器不做任何修改就可以满足需求了。通过具体的剥离、抽取我们成功了的最大限度的剥离了控制器，满足了轻量级Controller这一概念。