MVC，MVP和MVVM架构解析

---

关于架构，框架和设计模式三者的说明

• 架构
  架构是一种代码的管理方案，用来提高代码的可读性和可维护性，MVC，MVP，MVVM，或者自己对自己项目代码的管理方案都可以称为架构
• 框架
  框架是一种业务处理方案，是帮你写好的东西，已经完成部分业务，继承到自己项目中完成项目中部分功能，像okHttp,Retrofit,Glide等第三方库可以成为框架
• 设计模式
  设计模式是功能的实现方案，是能达到某种目的的一种代码的写法，以后也会对各种设计模式进行详细的讲解

---

一、MVC

1.概念

MVC, 即Model-View-Controller, 基于页面逻辑的修改要多于业务逻辑, 分离两种逻辑减少类代码的修改

2.结构

• Model: 即数据层, 负责处理业务逻辑, 监听网络与数据库接口
• View: 即界面(UI)层, 显示来源于Model的数据
• Contoller: 即逻辑层, 传递用户的交互和更新Model的数据
  

3.模式

根据MVC架构, View和Controller都会依赖于Model, View显示Model数据, Controller更新Model数据. Model从项目中分离后, 独立于UI, 允许测试. 更新Model方式的不同, 把MVC架构分为被动(Passive)模式和主动(Active)模式.

• 被动模式：在被动模式中, Controller是唯一操作Model的类. 基于用户的响应事件, Controller通知Model更新数据. 在Model更新后, Controller通知View更新UI, View从Model中获取数据
  
• 主动模式：在主动模式中, Controller不是唯一操作Model的类, Model存在自更新机制. 在更新数据时, Model层使用观察者(Observer)模式通知View和其他类. View实现观察者的接口, 在Model中, 注册成为观察者, 接收通知.
  
  当Model层发生数据更新时, 告知全部观察者. View从Model中更新数据.
  

4.优缺点

• 优点：MVC模式, 分离类的UI与业务职责, 增加可测试性与可扩展性. Model不引用任何Android类, 允许单元测试(Unit Test). Controller含有View的引用, 不引用Android类, 允许单元测试. View满足单一职责原则(SRP), 传递事件至Controller, 展示Model数据, 不包含业务逻辑, 允许UI测试.
• 缺点：
  1.View既依赖于Controller又依赖于Model. 在修改UI逻辑时, 也需要修改Model, 降低架构的灵活性. View与Model的职责部分重叠, 过于耦合, 在处理UI逻辑时, 被动模式与主动模式都会产生若干问题.
  2.在被动模式中, Controller通知Model更新数据, 并通知View显示. 对于UI逻辑, 如果View处理, 单元测试会遗漏逻辑; 如果Model处理, 则隐式地依赖于View, 导致模块增加耦合
  3.MVC架构含有致命问题, 即View同时含有Controller与Model的引用; UI逻辑同时存在于View与Model之间. 这些问题导致业务逻辑与UI逻辑无法分离, 增加模块耦合, 影响重构. 这些问题在MVC的进化版MVP中逐步解决.

5.适用场景

项目体量较小，维护频率不高的应用

二、MVP

1.概念

MVP属于MVC的演化版本，目的是让Model和View完全解耦

2.结构

• View：对应于Activity，负责View的绘制以及与用户交互
• Model：业务逻辑和实体模型
• Presenter：负责完成View于Model间的交互

3.与MVC对比

• MVC下的数据走向
  
• MVP下的数据走向
  
• 与MVC的区别对比
  最明显的区别就是，MVC中是允许Model和View进行交互的，而MVP中很明显，Model与View之间的交互由Presenter完成。还有一点就是Presenter与View之间的交互是通过接口的
  

4.优缺点

• 优点：
  1.降低耦合度
  2.模块职责划分明显
  3.利用测试驱动开发
  4.代码复用
  5.代码灵活度增加
• 缺点：
  由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了

5.适用场景

项目如果过于庞大，且需要频繁对于VIEW进行调整或者变更的项目不适用于此模式常规的中小型应用适合于当前业务需求

---

三、MVVM

1.结构

• Model:数据层，包含数据实体和对数据实体的操作
• ViewModel：关联层，将Model和View进行绑定，Model或者View更改时，实时刷新对方。ViewModel只做和业务逻辑相关的工作，不涉及任何和UI相关的操作，不持有控件引用，不更新UI
• View只做和UI相关的工作，不涉及任何业务逻辑，不涉及操作数据，不处理数据。UI和数据严格的分开

2.解析

• View显而易见Activity/Fragment便是MVVM中的View，当收到ViewModel传递过来的数据时，Activity/Fragment负责将数据以你喜欢的方式显示出来。View还包括ViewDataBinding，图中并没有体现。
• ViewModelViewModel作为Activity/Fragment与其他组件的连接器。负责转换和聚合Model中返回的数据，使这些数据易于展示，并把这些数据改变即时通知给Actvity/Fragment。ViewModel是具有生命周期意识的，当Activity/Fragment销毁时ViewModel的onClear方法会被回调，你可以在这里做一些清理工作。LiveData是具有生命周期意识的一个可观察的数据持有者，ViewModel中的数据有LiveData持有，并且只有当Activity/Fragment处于活动时才会通知UI数据的改变，避免无用的刷新UI。
• ModelRepository及其下方就是model了。Repository负责提取和处理数据。数据来源可以是本地数据库，也可以来自网络，这些数据统一有Repository处理，对应隐藏数据来源以及获取方式。
• Binder绑定器Android中的数据绑定技术由DataBinding和LiveData共同实现。当Activity/Fragment接收到来自ViewModel中的新数据时（由LiveData自动通知数据的改变），将这些数据通过DataBinding绑定到ViewDataBinding中，UI将会自动刷新。

3.MVVM架构本质

1.解耦，区别于MVC不会产生巨量代码，区别于MVP不会产生大量接口
2.职责更加明确，在mvp模式中，p需要持有V的引用，才能去刷新UI，在MVVM模式中，View和Model使用databingding进行双向绑定，一方改变会直接通知另外一方，使得viewModel能专注于业务逻辑的处理，而不需要去关心UI刷新

4.DataBinding和MVVM关系

MVVM是一种架构模式，DataBinding是一个实现数据和UI绑定的框架，是实现MVVM模式的工具

5.优缺点

• 优点：
  1.使得M,V,VM的解耦更加彻底，在mvp模式中，p需要持有V的引用，才能去刷新UI，在MVVM模式中，View和Model使用databingding进行双向绑定，一方改变会直接通知另外一方，使得viewModel能专注于业务逻辑的处理，而不需要去关心UI刷新
  2.不会像MVC一样导致Activity中代码量巨大，也不会像MVP一样出现大量的View接口(Presente与View是通过接口进行交互的)。项目结构更加低耦合。

• 缺点：
  1.数据绑定使得Bug很难被调试
  2.一个大的模块中，model也会很大，虽然使用方便了也很容易保证了数据的一致性，但是长期持有，不释放内存，就造成了花费更多的内存
  3.数据双向绑定不利于代码重用。客户端开发最常用的重用时View，但是数据双向绑定技术，让你在一个View都绑定了一个model，不同模块的model都不同，那就不能简单重用View了

6.适用场景

业务处理逻辑大多数在后端的情况下前端只要做展示而不需要做大量的业务处理的项目