引言

众所周知当下是 MVVM 盛行的时代，从早期的 Angular 到现在的 React 和 Vue ，再从最初的三分天下到现在的两虎相争

无疑不给我们的开发带来了一种前所未有的新体验，告别了操作 DOM 的思维，换上了数据驱动页面的思想，果然时代的进步，改变了我们许多许多

同时随着 MVVM 的成熟；也逐渐成为了架构师的必备技能，话不多说；我们来进入今天的主题

MVVM 是什么？

MVVM 可以算是 MVP 的升级版； 其中的 VM 是 ViewModel 的缩写，ViewModel 可以理解成是 View 的数据模型和 Presenter 的合体

ViewModel 和 View 之间的交互通过 Data Binding 完成，而 Data Binding 可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了 Activity 的压力

刚开始理解这些概念的时候认为这几种模式虽然都是要将 view 和 model 解耦，但是非此即彼，没有关系，一个应用只会用一种模式

后来慢慢发现世界绝对不是只有黑白两面，中间最大的一块其实是灰色地带，同样，这几种模式的边界并非那么明显，可能你在自己的应用中都会用到；实际上也根本没必要去纠结自己到底用的是 MVC、MVP 还是 MVVP，不管黑猫白猫，捉住老鼠就是好猫

MVC->MVP->MVVM 演进过程

MVC -> MVP -> MVVM 这几个软件设计模式是一步步演化发展的

• MVVM 是从 MVP 的进一步发展与规范，MVP 隔离了MVC中的 M 与 V 的直接联系后，靠 Presenter 来中转
• 使用 MVP 时 P 是直接调用 View 的接口来实现对视图的操作的，这个 View 接口的东西一般来说是 showData、showLoading 等等；M 与 V已经隔离了，方便测试了，但代码还不够优雅简洁
• MVVM 就弥补了这些缺陷； 在 MVVM 中就出现的 Data Binding 这个概念，意思就是 View 接口的 showData 这些实现方法可以不写了，通过 Binding 来实现

MVC -> MVP -> MVVM 三者的区别

先说一下三者的共同点，也就是 Model 和 View：

• Model：数据对象，同时，提供本应用外部对应用程序数据的操作的接口，也可能在数据变化时发出变更通知；Model 不依赖于 View 的实现，只要外部程序调用 Model 的接口就能够实现对数据的增删改查
• View：UI层，提供对最终用户的交互操作功能，包括UI展现代码及一些相关的界面逻辑代码 三者的差异在于如何粘合 View 和 Model，实现用户的交互操作以及变更通知

Controller

• Controller 接收 View 的操作事件，根据事件不同，或者调用 Model 的接口进行数据操作，或者进行 View 的跳转，从而也意味着一个 Controller 可以对应多个 View
• Controller 对 View 的实现不太关心，只会被动地接收，Model 的数据变更不通过 Controller 直接通知 View，通常 View 采用观察者模式监听 Model 的变化

Presenter

• Presenter 与Controller 一样，接收 View 的命令，对 Model 进行操作
• 与 Controller 不同的是 Presenter 会反作用于 View，Model 的变更通知首先被 Presenter 获得，然后 Presenter 再去更新 View；一个 Presenter 只对应于一个 View

根据 Presenter 和 View 对逻辑代码分担的程度不同，这种模式又有两种情况： Passive View 和 Supervisor Controller

ViewModel

• 注意这里的 “Model” 指的是 View 的 Model； 跟 MVVM 中的一个 Model 不是一回事，所谓 View 的 Model 就是包含 View 的一些数据属性和操作的这么一个东东，这种模式的关键技术就是数据绑定（data binding）
• View 的变化会直接影响 ViewModel，ViewModel 的变化或者内容也会直接体现在View上；这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互

MVP 和 MVVM 完全隔离了 Model 和 View； 但是在有些情况下，数据从 Model 到 ViewModel 或者 Presenter 的拷贝开销很大，可能也会结合 MVC 的方式，Model 直接通知 View 进行变更

在实际的应用中很有可能你已经在不知不觉中将几种模式融合在一起； 但是为了代码的可扩展、可测试性，必须做到模块的解耦，不相关的代码不要放在一起

案例小故事

网上有一个故事是这样的：一个人在一家公司做一个新产品时，一名外包公司的新员工直接在 View 中做了数据库持久化操作，而且一个 hibernate 代码展开后发现竟然有几百行的 SQL 语句，搞得他们惊讶不已，一时成为笑谈

个人理解，在广义地谈论 MVC 架构时，并非指本文中严格定义的 MVC，而是指的 MV * ； 也就是视图和模型的分离，只要一个框架提供了视图和模型分离的功能，我们就可以认为它是一个 MVC 框架；在开发深入之后，可以再体会用到的框架到底是 MVC、 MVP 还是 MVVM ?

好了，今天有关于 MVC、MVP、MVVM 的框架设计的阐述就到这里了；为了帮助大家了解更多架构师必备的技术知识，这里特别提供一份由腾讯大佬所整理的一份进阶架构师的思维导图及其配套的一份学习手册；有需要思维导图及学习笔记的朋友： 可以私信发送 “架构” 即可 直达获取；希望大家看完之后能给大家一些帮助

资料如下所示：

《架构师架构技术思维导图》

架构师架构技术必知六大设计原则

• 单一职责原则
• 开闭原则
• 里氏替换原则（LSP）
• 依赖倒置原则
• 接口隔离原则
• 迪米特法则（最少知识原则）

完整版 架构师思维导图及学习手册 获取方式：私信发送 “架构”即可 直达获取

架构师架构技术必知结构型模式与创建型模式

• 结构型模式基本概念
• 代理模式
• 适配器模式（Adapter 模式）
• 桥接模式（Bridge 模式）
• 创建型模式

架构师架构技术必知 MVC,MVP,MVVM 与架构

• 架构设计的目的
• MVC 设计架构
• Android 中的 MVC
• MVP 设计架构
• **MVP 架构存在的问题与解决办法
• MVC、MVP 与 MVVM 的关系
• MVC -> MVP -> MVVM 演进过程
• 基于 AOP 的框架设计
• AOP 在 Android 中的使用
• 干货：Android App 架构的设计经验

完整版 架构师思维导图及学习手册 获取方式：私信发送 “架构”即可 直达获取

架构师这个词，在我大学期间也觉得遥不可及；从来没有想到过自己有一天也会戴上这个头衔，其实，只要按照我上述的思路，按部就班，脚踏实地的不断的学习、进阶，并不难的；只看你有没有这个心罢了

并不要觉得自己离架构师的路有多少，千里之行始于足下；不要觉得自己的年纪已经成长不到架构师就要到35岁退休了，学习最好的时候，就是现在！