如何理解MVC和MVVM

在最近的一次面试中面试官问了一个问题，请你说说MVC和MVVM的区别，一时语塞，平时虽然在用像Vue、React这种MVVM框架，但是其细致的区别却不知道怎么描述，后面通过查阅资料使得自己的理解更深了，在此写出来一是方便自己记忆，二是也可以给有需要的人看看。
首先，我作为一个自学入行的，在这方面的积累上与科班出身的相比肯定是有所欠缺的，最明显的就是以我来说了解得更多的是如今的一些新技术，而对一些以往出现的技术及其演变过程是不了解的。之前粗略的看过MVVM是啥玩意儿，但是并没有在脑海中留下印象。废话不多说，下面开始。以下内容参考了b站教学视频BV137411N7aB，个人觉得很好理解。

此题其实涉及的知识点很多，比较难以说清、说透，因为要全部理解的话需要了解的web演变的过程、历史。
web1.0时代
首先要了解的便是web1.0时代，在这个时候并没有什么前端的概念。开发一个web应用多数采用ASP.NET/JAVA/PHP，一个项目通常由很多个aspx/jsp/php文件构成。每个文件中都糅杂了HTML.CSS,JS，C#/JAVA/PHP的代码。如下所示

此时这种架构的好处是简单快捷，但是缺点就是JSP这种代码非常难以维护，如果业务复杂，那后续维护的人真是要升天。所以为了让开发更加便捷，前后端职责更加清晰。便出现了MVC开发模式和框架，典型的框架就是Spring等。如下图所示

即M 各种功能模块
V 视图
C 业务逻辑控制
三者分层，使用这种分层架构时，职责更加清晰，代码更易维护。但是此时的MVC仅限于后端，前后端形成了一定的分离，前端完成了后端开发中的view层。
但是，这种模式同样存在这一些问题。如：1、前端页面开发效率不高（学习曲线太高，有广度没有深度，前端编写完静态页面加入js交互后还需要交由后端开发人员使用模板语法进行改造） 2、前后端职责不清

web2.0时代
ajax的出现和风靡带了新的契机。因为此时前端可以通过ajax与后端进行数据交互，因此整体的架构图也变了。如下

此时前端的任务变的更重了，同时前后端的职责划分就更加清晰了。前端开发人员止血药开发页面这部分的内容，数据可通过ajax由后台提供，并可以实现页面的部分内容刷新，减少了服务端的负载和流量消耗，用户体验更佳。此时，才有专职的前端工程师。与此同时前端的类库也开始慢慢的发展，比如JQuery。
当然，此架构也存在问题：1、缺乏可行的开发模式承载更负责的业务需求，页面内容都糅杂在一起，如果应用规模增大，依然会导致难以维护。因此，前端的MVC也随之而来。

前端分离后的架构演变 MVC MVP MVVM
前端的MVC与后端类似，都是View Controller Model
Model：负责保存应用数据，与后端数据进行同步
Controller：负责业务逻辑，根据用户行为对Model数据进行修改
View：负责视图展示，将Model中的数据展示出来
三者如下图所示：

但是这样的模型在理论上是可行的。但在实际开发中，这样的开发过程并不灵活。比如一个小的事件操作如果都要经过这样一个流程，那么开发就变得不便捷。
因此在实际场景中，我们会看到另一种模式。如下图

这种开发模式更加的灵活，比如backbone.js
但同时这种灵活也可能导致严重的问题，比如
1、数据流混乱，

当model变化时会改变对应的view，但同时view变化又会更改model，最后可能分不清是谁更改了。
2、view比较庞大,由于开发者都会在view中写一些逻辑代码，逐渐的就导致view中的内容越来越庞大，而controller变得越来越单薄。
有缺陷当然就会有变革。前端的变化中似乎少了mvp这种模式。是因为Angular的横空出世早早的将MVVM框架模式带入了前端。

MVP
mvp模式在前端开发中不常见，但是在安卓等原生开发中，开发者还是会考虑到。
mvp与mvc很接近，p指presenter，可以理解为一个中间人，负责view和model之间的数据流动，防止view和model之间直接交流，如下图

presenter负责和model、view进行双向交互。这种交互方式相对于MVC来说少了些灵活，view变成了被动视图，并且本身变得很小。虽然它分离了view和model。但是应用变大后会导致presenter的体积增大。又变得难以维护。但我将它视为最早期的mvvm

MVVM (Model-View-ViewModel)
ViewModel可以理解为Presenter的进阶，如图

1、ViewModel通过实现一套数据响应式的机制自动响应Model中的变化（响应式）
2、ViewModel会实现一套更新策略自动将数据变化转换为视图更新（diff算法）
3、通过事件监听响应view中用户交互修改model中数据
这样在viewmodel中就减少了大量的dom操作代码
MVVM在保持view和model松耦合的同时，还减少了维护他们关系的代码，可以使得开发者专注于业务逻辑，并兼顾了开发效率和可维护性。

总结
1、这二者都是框架模式，它们设计的目的都是为了结局Model和View的耦合问题
2、MVC模式早期主要应用在后端，在前端领域的早期也有应用。他的优点是分层清晰，缺点是数据流混乱，灵活性带来的不好维护问题
3、MVVM模式在前端领域又广泛的应用，它不仅解决了Model、View的耦合问题，还同时解决了维护两者映射关系的大量繁杂代码和DOM操作代码，在提高开发效率、可读性的同时还保持了优越的性能表现。