在解释MVP时，我们往往喜欢拿它和大众都比较熟悉的MVC进行比较。
MVC
MVC全名是 Model--View--Controller，是 模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
- Model 层处理数据，业务逻辑等
- View层处理界面的显示结果
- Controller层起到桥梁的作用，来控制View层和Model层通信以此来达到分离视图显示和业务逻辑层。
View：XML布局文件。
Model：实体模型（数据的获取、存储、数据状态变化）。
Controller：对应于Activity，处理数据、业务和UI。
从上面这个结构来看，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色，直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧！所以，更贴切的说法是，这个 MVC 结构最终其实只是一个：
-
Model-View（Activity:View&Controller）的结构
我们往往把Android中界面部分的实现也理解为采用了MVC框架，常常把Activity理解为MVC模式中的Controller。
MVP
而MVP其实是MVC的一种演进版本，它更简单，将 MVC中的Controller改为了Presenter，View通过接口与Presenter进行交互，降低耦合，方便进行单元测试。
其核心理念是通过一个抽象的 View 接口（不是真正的View层）将 Presenter 与真正的 View 层进行解耦。Persenter 持有该View接口，对该接口进行操作，而不是直接操作 View 层。这样就可以把视图操作和业务逻辑解耦，从而让 Activity 成为真正的 View层。
- View:对应于Activity和XML，负责View的绘制以及与用户的交互。
- Model:依然是实体模型。
- Presenter:负责完成View与Model间的交互和业务逻辑。
区别
我们看看如下的MVC和MVP的对比图更能直观的理解这两种模式的区别：
最明显的区别就是，MVC中是允许Model和View进行交互的，而MVP中很明显，Model与View之间的交互由Presenter完成。
那么我们为什么需要MVP或者其他模式呢？现实中，我们常遇到一些不使用架构的项目（程序员都很任性，功能需求到哪里代码就写到哪里），需求中的一个页面对应项目中的一个activity或一个fragment，所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中，一个类的代码非常臃肿难于理解和维护。
如何在自己的项目中使用MVP
MVP的好处与问题
当你了解清楚MVP模式后，它的好处也就很明显了：
- UI层和逻辑层分离，UI层不在涉及业务逻辑代码，某层的改动不需要到处去修改代码；
- 测试很方便，你可以直接调用Presenter层写测试用式（可以使用Junit框架）；
- 最后是可维护性和可扩展性，MVP的各个类职责都非常明确且单一，后期的扩展，维护都会更加容易。
MVP 模式的缺点
- Presenter（以下简称P）层与View（以下简称V）层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化；粒度太大，解耦效果不好。同时对于UI的输入和数据的变化，需要手动调用V层或者P层相关的接口，相对来说缺乏自动性、监听性。如果数据的变化能自动响应到UI、UI的输入能自动更新到数据，那该多好！
- MVP是以UI为驱动的模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候要考虑当前是否是UI线程，也要考虑Activity的生命周期（是否已经销毁等）。
- MVP是以UI和事件为驱动的传统模型，数据都是被动地通过UI控件做展示，但是由于数据的时变性，我们更希望数据能转被动为主动，希望数据能更有活性，由数据来驱动UI。
V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变，牵一发而动全身。如果这一层也能解耦就更好了。 - 复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决。
参考链接
