MVC是一种架构设计，通过关注点分离鼓励改进应用程序组织，其强调将业务数据（model）和用户界面（view）隔离，用第三部分控制器（controller）管理逻辑和用户输入。
MVC其实是早期软件开发大牛想实现关注点分离时提出来的，后来也被广泛的使用在软件设计开发中，随着web大行其道，逐渐有人在web前端开始使用MVC模式，但很多框架其实更像是使用了MVC的变种MV*。
因为在前端其实view和model是没什么问题的，view是视图，代表界面呈现，通常是相对于M和C高度封装的，被动根据model变化，model代表模型，储存着状态或数据，接受C控制改变，通知V根据数据变动进行响应，但有一些Controller的行为跟传统的C行为并不相同，所以有的C变成了VM（view-model），有的变成了P（presentation）。
回到MVC上，在MVC中，V通常订阅一个Model，并在model变化时接受通知，呈献给用户的是其从model中读取呈现的数据，也被指为“愚钝的”，对C和M的了解都是有限的；M存储应用程序需要的数据或状态，呈现为一整个的数据集以及处理数据集的方法，通常被一个或多个视图观察，接受controller带来的请求改变；C根据V传来的不同行为，采取不同的策略改变model，而model则会发布相应改变，C充当M和V之间的中介，控制整个模块的流程。
如上图所示，其中实线表示存在方法调用，虚线表示事件订阅
MVC这种关注点分离的模式让开发流程变得规范清晰，简化应用程序功能的模块化，其好处有以下几点：
1.MVC各部分组件逻辑清晰，耦合低高内聚，所以在定义好接口的前提下，业务和逻辑开发可以同时进行
2.组件分隔良好，有利于后期维护或改版，职责单一，分工明确，引起页面改变的点清晰明了
3.数据和视图耦合低，代码逻辑结构清晰，可以更直接的编写业务逻辑单元测试
4.底层Model和controller的重复代码消除了
不可否认MVC模式比较符合单一职责原则，但MVC模式也存在相应的缺陷不足
比较直观的就是C作为中介者，其内部逻辑对应V的每一种行为，并直接调用M的方法，随着功能增多以及V数目增长，C的结构就越冗杂，可复用性就越差。
总结：实际上，我们可以将MVC作为以观察者模式为中心，策略模式，组合模式三种设计模式的组合，其核心关注视图，而视图订阅模型的变化，同时用户在对视图进行一系列行为时，controller通过策略模式对行为进行区分，使用符合策略的方法对具有一定反应视图逻辑结构的Model中数据进行操作，三者看似联系紧密却又井然有序封装良好。
那么如何处理C复用性差的问题呢？那就是接下来讲的MVP（model view presenter）模式
让我们想一想，在MVC中既然C已经和V、M强耦合，那么我们何不直接将V和M之间的逻辑也全部加到P上，完全解耦V和M，成为更加纯粹的中介者模式，而另一种更“激进”的思路将C变为VM则是MVVM，这个是后话了，我们先讨论MVP。
基本细节如下图 
在MVC里面，V和M存在发布订阅联系，而MVP中，V和M二者完全解耦、职责单一清晰，此时view只专注于视图层，只需设置好与P的接口即可
笔者对MVP模式了解不多，暂时就到此为止了，下面接着讲MVVM模式
MVVM
MVVM即Model View View-Model，同样是将view和model解耦，其试图更清晰的将用户界面开发从应用程序的业务逻辑与行为分离，在其中利用声明式数据绑定来实现将View工作从其他工作层中分离。其中M和V类似于MVC的，但也有一些区别，区别关键就在于VM，其运行机制是view中数据改变后利用数据绑定影响VM中的数据，VM数据进一步改变model中储存的数据和状态，model再传递一个改变确认给VM，由VM传递给view进而改变界面，总体来说，MVVM是在MVP的基础上将P与M、V的接口交互逻辑自动化。
model表示应用程序中储存的信息或状态，收到VM中的更新请求后会进行检验然后改变，并将改变传回VM
view表示UI层，实际上只是与用户进行交互的应用程序的一部分，其将vm的数据格式化后呈现在界面上，同时还有一些vm的逻辑，可能包括事件绑定和数据绑定等，用户操作后通过双向绑定改变vm中的状态，同时接受vm中传递过来的数据变更进行变化。
view-model是view和model的中间层，可以理解为view和model都有一点，保存着主要的业务和行为逻辑，将用户操作的响应，储存传递给model的更新，同时作为v数据和m中原始数据的中间层，数据将会在这里进行转化后被view调用。简单说，其将model信息转化为view信息，将view命令传递给model
优点：
1.UI与业务逻辑分离，可以同时进行开发
2.代码低耦合高内聚，组件清晰，结构分明，有利于单元测试、错误修改和后期维护
3.使view抽象化，减少代码背后所需的业务逻辑量
4.不需要考虑UI自动化和交互就可以测试view-model
缺点：
1.不适合简单应用开发，可能会使简单事务变得相对复杂
2.对于大型应用或业务逻辑复杂应用，绑定可能会比被绑定的对象还要繁琐，VM层可能会变的庞大难以维护，预先设计VM可能更加困难
3.数据绑定是声明式的，适用方便，但比命令式更难调试，在命令式代码中，我们只需要设置断点
总结：作为MV*中一员，MVVM主要专注于将UI层于业务逻辑层分离，实现VM和M数据驱动V
前端圈十分繁荣，各种框架层出不穷，但纵观本质很多核心思想都是类似的，努力做到抽象封装解耦复用，内含观察者、中介者模式等一系列模式，都符合单一职责、最少知识、开放封闭原则，这是思维的智慧结晶，也是哲学以及艺术的完美结合，希望大家一起加油，在开发过程中多思考总结造*，为前端繁荣做出自己的一份贡献。