一、MVC架构

image

简介：

• M对应Model，代表业务数据
• V对应View,代表视图
• C对应Controller，代表控制器。

用户通过界面组件进行操作，也就是View层，相应的动作会传递给控制器也就是Controller层，而Controller根据自己的业务逻辑去操作数据层也就是Model，而最终数据层的变化会同步更新到视图层。

目的：
可以看到MVC的主要目的是为了视图和数据分离，这对于开发大型软件来说更方便进行模块的划分，提高编码速度与质量。

优点：

• MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。
• MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

缺点：
从图示中也可以看出，在View和Model之间是直接进行交互的，也就是说View和Model之间是可以相互产生影响的，这样在代码中就必然会导致View和Model之间的耦合。

Android中的MVC

Android世界中也经常运用到MVC模式。 Activity对应视图界面也就是View层。 数据库文件，Sharedprefrence,内存缓冲，磁盘缓冲等数据内容对应Model层。 而Controller控制层基本上也由Activity层面来进行。

Android中mvc中基本动作流程

1.在layout制定相应的布局文件，然后显示在Activity上。这对应于View层，这里的View并不是Android中开发中的组件view而是对视图的统称.
2.Activity在onCreate方法或者onResume方法去服务器获取数据，或者通过界面上的某个按钮之类去启动获取服务器数据的任务，这里就对应到View—>Controller，只不过这里的View和Controller对是由Activity来完成。
3.Controller获取到了数据之后，分别存在，内存、磁盘和数据库中，并且数据获取成功或者失败后，Activity界面需要同步更新状态。这由对应上面流程中的Controller—>Model 和Model—->View。

二、MVP架构

MVP架构就是MVC的一个演化版本。上面讲解了MVC的基础知识，大家可能觉得MVC挺好的啊？怎么还要整一个MVP。是的MVC是挺好的，但是它也有它的缺点，特别是针对Androi开发。

因为Android的特殊性，使得Activity对应了MVC中的V和C,同时担任两个角色，就有了类似“既当爹又当妈”的感觉，这显然就不符合软件设计原则的“单一职责”原则。但现实中是很多的APP代码中有这么的处境，特别是Androi原生的很多系统APK，某些Activity动则几千行代码。

况且，随着项目的深入发展，很多逻辑很越来越复杂，Activity处理的东西也会越来越多，代码越来越臃肿。这样一来维护起来的代价就会越来越高，这是因为View的变化会引起Controller的很多变化，反之亦然。

而MVP就是要减轻在Android中的这种困惑。
MVP是基于MVC的，它的架构图如下：

image

• M(Model) 数据相关层
• V(View) 视图层，如Activity上的布局
• P(Presenter) 纽带层，用来连接Model与View

优点：
1、模型与视图完全分离，我们可以修改视图而不影响模型；
2、项目代码结构（文件夹）清晰，一看就知道什么类干什么事情；
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁
4、协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码或者其他人接手代码改起来比较容易）

缺点：
1、Presente层与View层是通过接口进行交互的，View层可能会有大量的接口，因为有可能好几个Activity都是去实现同一个View接口，那么所有用到的Activity都要去实现所有的方法(不管你是否用到)，而且如果后面有些方法要删改，Presenter和Activity都要改动，比较麻烦；
2、MVP把Activity相当的一部分责任放到了Presenter来处理，复杂的业务同时也可能会导致P层太大，一旦业务逻辑越来越多，View定义的方法越来越多，会造成Activity和Fragment实现的方法越来越多，依然臃肿。

MVP开发在Android中的基本流程

1. View层定义View.interface，用来定义View的行为。一般由Activity或者是Fragment来实现这个接口，它定义了View视图的各种变化，如设置Textview,加载对话框，更新进度条等。
2. Model层定义Modle.interface,这个是用来定义数据层发生变化时的通知接口，因为Model不能直接与View交互，所以它与Presenter交互，然后再通过Presenter间接达到与View的交互。
3. Presenter翻译的意思是主持人，也就是主持场合，控制节奏的意思。在这时Presenter就负责具体的业务逻辑，请求数据，把数据送到Model，或者监听Model的数据变化，接受View层的动作，负责通过通知View层的视图变化。

如果跟MVC的架构图对比的话，可以发现它们有相似之处也有不同。

与MVC模式对比

1.MVC由Model、View、Controller构成。 MVP由Model、View、Presenter构成。
2.MVP中Presenter取代了MVC中的Controller。
3.MVC中Model、View、Controller之间相互发生通信，而MVP中Model与Presenter相互通信，View与Presenter相互通信，而Model与View之间没有通信。

Android中MVP的好处？
就Android层面上来讲MVC架构虽然好，但不是最好，情况前面有讲过。用一句话概括就是“模块界限很模糊”。而MVP的出现实际上就是将MVC进行升级，对应Android开发中就是帮助Activity解压。
MVC中Activity同时充当了V和C的角色，这就属于界限划分不清楚。而MVP则划分的很清楚，Activity只充当V的角色，业务逻辑控制交给了Presenter。

三.MVVM架构

image

MVVM模式与MVP模式一样，也将应用分为三层，并且各个对应的层的职责相似：

• Model层，主要负责数据的提供。Model层提供业务逻辑的数据结构（比如，实体类），提供数据的获取（比如，从本地数据库或者远程网络获取数据），提供数据的存储。
• View层，主要负责界面的显示。View层不涉及任何的业务逻辑处理，它持有
  ViewModel层的引用，当需要进行业务逻辑处理时通知ViewModel层。
• ViewModel层，主要负责业务逻辑的处理。ViewModel层不涉及任何的视图操作。通过官方提供的Data Binding库，View层和ViewModel层中的数据可以实现绑定，ViewModel层中数据的变化可以自动通知View层进行更新，因此ViewModel层不需要持有View层的引用。ViewModel层可以看作是View层的数据模型和Presenter层的结合。

MVVM模式与MVP模式最大的区别在于：ViewModel层不持有View层的引用。这样进一步降低了耦合，View层代码的改变不会影响到ViewModel层。

MVVM模式相对于MVP模式主要有如下优点：

• 进一步降低了耦合。ViewModel层不持有View层的引用，当View层发生改变时，只要View层绑定的数据不变，那么ViewModel层就不需要改变。而在MVP模式下，当View层发生改变时，操作视图的接口就要进行相应的改变，那么Presenter层就需要修改了。
• 不用再编写很多样板代码。通过官方的Data Binding库，UI和数据之间可以实现绑定，不用再编写大量的findViewById()和操作视图的代码了。总之，Activity/Fragment的代码可以做到相当简洁。

DataBinding :
DataBinding数据绑定库是一种支持库，借助该库，您可以使用声明性格式（而非程序化地）将布局中的界面组件绑定到应用中的数据源。

作者：mumuxi_
链接：https://www.jianshu.com/p/965f9912d4d7
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。