关于MVP是现在比较热门的模式之一它取代了传统的MVC模式;

MVP模式下表示层的优势体现在下面三个方面：

1、View与Model完全隔离。
得益于此，Model和View之间具有良好的松耦合设计，这意味着，如果Model或View中的一方发生变化，只要交互接口不变，另一方就没必要对上述变化做出改变。这使得Model层的业务逻辑具有很好的灵活性和可重用性。
2、Presenter与View的具体实现技术无关。
也就是说，采用诸如Windows表单，WPF，Web表单等用户界面构建技术中的任意一种来实现View层，都无需改变系统的其他部分。甚至为了使B/S，C/S部署架构能够被同时支持，应用程序可以用同一个Model层适配多种技术构建的View层。
3、可以进行View的模拟测试。
过去，由于View和Model之间的紧耦合，在Model和View同时开发完成之前对其中一方进行测试是不可能的。出于同样的原因，对View或Model进行单元测试很困难。现在，MVP模式解决了所有的问题。在MVP模式中，View和Model之间没有直接依赖，开发者能够借助模拟对象注入测试两者中的任一方

M：Model层，数据服务层，负责数据的增删改查。在服务端就包括mysql数据库操作、本地cache等；在客户端就包括调用服务器API、各种形式的数据缓存等。有些朋友将Model层理解为数据模型层，数据模型归根结底是数据，设计数据模型是为了在面向对象的程序设计中更好的表达数据。所以数据模型贯穿于整个应用程序，不应该将Model层单单理解为是数据模型。但Model层往往负责将接收到的数据转化为相应的数据模型供上层使用。
V：View层，视图界面层，负责UI的渲染、子视图的组织、UI事件、用户交互等。在有些网友看来，View层是比较轻的一层，大多数时候只需要调用系统的UI控件，绑定需要的UI事件就完事了，很多平台甚至拖拖控件就行。但是实际上是因为平台为我们做了大多数的事，我们不需要去考虑怎么有效的渲染界面，也不需要去考虑怎样去实现各种各样的交互事件(触摸)，只需要关注应用本身就可以了。
P：Presenter层，有得朋友将其叫作发布者，百度翻译为主持人，笔者觉得后者更贴切些。 Presenter既是中间人，在View和Model之间起到桥梁的作用，又是一个独立的大模块，封装了业务的复杂度，将UI和业务逻辑拆分开来，使UI和业务都可以独立的进行变化。从整体的数据流向上看，Presenter从Model层获取数据，并通过接口发送给View层展示；View层将用户交互传递给Presenter，由Presenter完成相应的业务逻辑，这其中可能会有Model层的参与，比如Presenter调用Model层的接口来保存数据。

今天就进行简单的整理