MVC
当一个问题出现一次的时候它是一个问题，当一个问题出现了无数次的时候它会成为历史，当一个问题将会出现无数次的时候，它将需要一个明确的定义和解决方案。
MVC 是什么
简单而言，model、view、controller，一种应用的、通用的框架模式。
model、view简单易懂，因为字面意思纯粹。而controller，每个人在不同领域，都有解释各自具体的解释，所以，回答并不相同，因为MVC。如果说MVC去描述一个项目，那controller就是除了view、model以外的所有。你也可以说不是，说controller就是负责处理业务的业务逻辑，那MVC就是去描述一个项目的主要架构。
那给MVC一个更合适的定义：M，model，数据，数据侧，负责数据存放，也可以将获取数据的操作方法放在数据文件中。V，view，视图，视图侧，负责视图显示，也可以将视图事件监听放一块。C，controller，可以是除M、V以外的方法，但至少负责处理业务逻辑，连接数据与视图。
MVC 到底是什么
诗人，为什么作诗，又为何饮酒，还得去了解当时发生什么。
...
最早的程序是汇编，当时的码农的工作是兼职，工作内容是编写一套寿命不长的机器控制指令，有些甚至是命令，比如至今依然保留的Command。
...
代码越写越长，Code Block将文件分割成块。但有时又大可不必，于是有Code Inside，简单就无需分开。简单，又没那么简单，Code Behind帮助缓解这份尴尬。
...
或许显示技术提示带来的界面功能复杂，或许是视图代码上卷出了新的高度，view不得不但单独提出来提高重视。MVC模式自然而然被抽象出来，成为行业共识
...
MVC后出现更严格的MVP，结合MP又诞生更方便的MVVM
...
对每个开发者来说，MVC模式重要的是共识，毕竟平时维护通常都不是自己的项目。
先有鸡还是先有蛋？但肯定不是先有前端。前端作为互联网分支职业，有必要汲取软件历史中难能可贵的经验。MVC等可以在前端中有更多更深的表现形式，但一定不是MVC等模式最好的解释，即 很难从前端给出MVC最好的定义。
vue没有完全遵循 MVVM 模型
因为在vue的view可以通过$refs直接访问 model。
这句话如何去理解，为什么view访问model显得这么严重，值得vue在官文中提出来说了又说？（参考创建一个实例、 v-el 和 v-ref 替换），还得回看历史。
MVP
MVP在wiki上表述内容十分简短，在各个作者口中也是简单带过，因为MVP只是MVC上延伸的软件设计模式，它只强调一点：view不能直接访问model，必须通过presenter代理 ，在MVVM中也强调view只能与viewModel交互。
而在MVC时代，MV并没有严格的限制，这其中发生了什么？这还得从工业的角度去观察
model是存放电脑的数据，view是给人交互的界面。一般情况，数据不能直接到视图中直接使用，需要经过处理。在哪处理？复杂的，我们会讲究地放在C中，那简单的呢？是不是总有人放在Model中专门处理存放 或是 直接将model引入view文件中处理使用？
然后，model为view设计的数据越来越多，或是view直接引用model也舒适得很，你说你不会，那项目下一个人或是上一个人会吗？接手项目往往是按照前人的写法继续写下去...
接着，项目更迭，model中脏数据越来越多，不敢清理。view中既然能访问，如果只是简单的逻辑，直接串改model多方便？是的，有人会这么做，这即是噩梦的开端...
MVVM是什么，又在vue中如何表现
MVVM也被称为model-view-binder，MV照旧，多出一个VM（视图模型，ViewModel），还隐含了一个绑定器（binder）。
VM如同vue中的vue实例（原文：文档中经常会使用 vm (ViewModel 的缩写) 这个变量名表示 Vue 实例），binder如同<template>中的模板绑定。
MVVM还重要的一点是数据驱动，即Vue中的 observer，区别与MVC的事件驱动。同时缺点伴生，MVVM的创造者John Gossman本人指出，实现MVVM的开销对于简单的UI操作是“过度的”。非常大的应用程序中的数据绑定会导致相当大的内存消耗。
当然，这些弊端尤大大也回答过 # 前端页面热数据太多... Vue 性能怎么样
我也一直记得尤大吐槽的一句话：用 React 也没什么不好，无非就是性能差点。（🤣哈哈哈哈hhhha...）
拓展
2012年尤大对前端MVC是不认可的，只有MV+X（应该是ajax），更新页面还得靠window.reload()。这篇文章也是尤大那几年唯一点赞上百的，其余都无人问津。vue最初版本也是v0.7，时间为8年前，在发版之前，一定也是一段漫长的岁月。
