MVP和MVC java_个人总结：MVC和MVP的区别

前言

各位老铁，历时20天我又回来了。时间嗖嗖就到年底了，才发现自己年初的计划还没开始，所以这一段时间都在专心研究后端的技术。刚开始接触MVC和MVP的时候，一直都有一个疑问，他俩到底有什么区别呢，面试的时候也经常被问到这个问题。我们都知道后端主要使用MVC，因为平台的特殊性，Android根据MVC模式演变出MVP模式，广泛的使用在开发中。

现在让我们怎么思考一下，为什么在Android平台演变出MVP模式？

本文参考了以下两篇博客，大家可以去阅读原文：

正文

首先看一下MVC和MVP的对比图(我直接偷来的)：

通过对比图我们分析一下两种模式的特点：

MVC

View：布局的xml文件，或者纯Java写的布局，可以把页面显示的逻辑直接放在View中。

Model：数据处理层，可以直接和View进行交互。

Controller：把特定的功能逻辑抽离出来，作为控制层，保证View层和Model层的功能单一性，便于维护。

MVC模式相对比较简单，尤其是View层，我们可以通过jsp等技术直接操作页面，完成和Controlller层和Model层的交互，所以MVC的核心是在View层。

接下来我们再看看MVP模式：

MVP

View：Activity作为显示层。

Presenter：逻辑层，从Activity中抽离出功能逻辑，简化Activity的代码。

Model：数据处理层，主要负责网络请求，本地数据加载等操作，进一步简化Activity的代码。

从MVP的构成来看，Presenter和Model都是为了View层存在的，所以MVP的核心仍然是View层。

MVP的演变

刚才我们分析了MVC和MVP的构成，我们发现MVP模式相比MVC模式要复杂：

MVC的View层和Model层本身就是分离的，Controller层主要是简化View层的逻辑代码。

MVP的Presenter层和Model层都是为了拆分View层而存在的。

Activity在Android开发中扮演者重要的角色，页面显示，数据加载，各种事件，他一个人可以承担所有相关的功能。虽然通过xml方便了布局的开发，但是在与后端开发中的xml相比，他并没有承担起显示UI的责任，所以Activity变得越来越庞大，轻轻松松就可以几千行代码，非常不利于维护，为了让View层单纯的负责UI的显示，把Activity中的功能逻辑抽离出来，命名为Presenter层，把数据相关的操作(接口，本地数据库等)提取成Model层，并且直接把View层和Model层通过Presenter层解耦，进一步简化Activity的代码，防止Activity体积过大。

MVC和MVP的区别

这里主要说他们的不同点：

1、Presenter与Controller都扮演了逻辑层的角色，但是Presenter层的功能相对更复杂，因为他负责和View的双向交互，Controller只是单向的中介。因为Presenter是从View层抽离出来的，通常和View是一对一的关系，而Controller是面向业务的，往往是单例模式或者提供静态方法。

2、MVP中View和Model是不能进行通信的，虽然加重了P层的负担，但是有利于维护View层和Model层，如果条件允许，我们还可以对Presenter进一步拆分，来弥补Presenter负担过重的问题。

3、MVC中View和Model层可以直接交互，虽然方便了两者之间的交互，但是耦合性相对较高。

其他的不同点就不说了，本来两种模式的出发点就不同，不同点那肯定导出都是，细说这些其实没有什么太大意义。

总结

“Android为什么没有使用MVC，而是使用MVP?"

如果还有人再问我这样的问题，我就可以轻松的说出我自己的见解，而不是毫无底气的猜测。

没有最好的架构模式。随着业务的不断增长，为了让我们的代码变得更美观，我们可能会多种模式混合使用，再或者在原本的模式上衍生出新的模式，这就是架构的魅力。看来我这20几天还是没白学的。

马上要十一了，最后祝大家国庆愉快~

?

?