简称：MVP 全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

MVP从MVC演变而来，通过表示器将视图与模型巧妙地分开。在该模式中，视图通常由表示器初始化，它呈现用户界面（UI）并接受用户所发出命令，但不对用户的输入作任何逻辑处理，而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器，但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器，每个表示器完成该视图的一部分业务处理工作，降低了单个表示器的复杂程度，一个表示器也能被多个有着相同业务需求的视图复用，增加单个表示器的复用度。表示器包含大多数表示逻辑，用以处理视图，与模型交互以获取或更新数据等。模型描述了系统的处理逻辑，模型对于表示器和视图一无所知。

MVP的全称为Model-View-Presenter，Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。

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之间没有直接依赖，开发者能够借助模拟对象注入测试两者中的任一方。

MVP是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。

在MVC里，View是可以直接访问Model的。从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用。不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候，就可以通过编写MockObject（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。在MVP里，应用程序的逻辑主要在Presenter里实现，其中的View是很薄的一层。因此就有人提出了PresenterFirst的设计模式，就是根据UserStory来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View，而对Presenter没有任何的影响了。如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和Presenter之间放置一个Adapter。由这个Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model--这就是与MVC很大的不同之处。

MVP与MVC的主要区别是View与Model不直接交互，而是通过与Presenter来完成交互，这样可以修改视图而不影响模型，达到解耦的目的，实现了Model和View真正的完全分离。视图的变化总是比较频繁，将业务逻辑抽取出来，放在表示器中实现，使模块职责划分明显，层次清晰，一个表示器能复用于多个视图，而不需要更改表示器的逻辑（当然是在该视图的改动不影响业务逻辑的前提下），这增加了程序的复用性。数据的处理由模型层完成，隐藏了数据，在数据显示时，表示器可以对数据进行访问控制，提高数据的安全性。以前的Android开发是难以进行单元测试的，但是随着项目变得复杂，测试时保证应用质量的关键，MVP模式中，表示器对视图是通过接口进行的，可以利用测试驱动，模拟出视图对象，实现视图相对于表示器的接口，就可以对表示层进行不依赖于UI环境的单元测试了，这大大降低了Android应用开发中的业务逻辑测试难度和复杂度。MVP模式的引入，视图层完全不依赖与模型层，相当于将视图从特定的业务场景中脱离出来，做到了对业务完全不可知的状态，因此可以将视图层组件化，提供一系列接口供表示层操作，这样就可以做出高度可复用的视图组件了。

MVP的明显缺点是增加了代码的复杂度，特别是针对小型Android应用的开发，会使程序冗余。Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，会导致Presenter臃肿，维护困难。视图的渲染过程也会放在Presenter中，造成视图与Presenter交互过于频繁，如果某特定视图的渲染很多，就会造成Presenter与该视图联系过于紧密，一旦该视图需要变更，那么Presenter也需要变更了，不能如预期的那样降低耦合度和增加复用性。