MVC、MVP、MVVM

MVC

mvc其实是从后端mvc架构模式中演变而来的，在2005年之前，也就是ajax还没有出现在前端世界中的时候，页面的处理其实都是由后端一人完成，全栈大师，那会前端技术还是很简单的，后端一个人就能实现从数据库拿数据然后渲染成一个完整html页面返回给浏览器。

但是就是这个过程耦合度很高，以至于不太好维护代码，于是采用了一种分层模式，将不同的代码分为不同的部分，也就是解耦处理，总共分为三层：模型层（Model）、视图层（View）、控制器层（Controller）。

模型层就是数据库的模型，如果使用过面向对象的数据库框架，比如sequelize，他们将每一个数据库的表转换成一个对象，通过操作这个对象的方法和属性实现对数据的改写，这个对象被称为模型。

视图层在那时其实是通过模板引擎来渲染html文本的，先通过控制器获取模型的数据，然后将变量放入模板中，模板编译后生成html文件返回给浏览器渲染。

控制器用于连接视图层和模型层，提供获取视图数据的方法，调用视图模板生成html返回给浏览器，属于一种沟通作用。

随着2005年2月的ajax发布，加上前端的知识越来越多，光后端一个人处理已经做不到了，加上ajax的出现，前端可以通过请求的方式获取到数据，已经不需要和后端混在一起开发了，于是出现了真正意义上的前后端分离开发。

前端分离后，前端也是需要处理代码的维护性，于是借鉴了后端的mvc分层架构模式，衍生了自己的mvc。

前端的模型层，其实真正意义上是获取数据的对象，它可以通过ajax异步请求获取数据，然后对数据进行处理。

而视图层大部分都是定义为一个返回html字符串的函数

控制器用于连接模型层和视图层，响应dom操作，给视图层提供模型层的数据，承载业务逻辑。

理论很美好，但是在实际开发过程中，mvc更像是理论上的抽象，各家对mvc的实现都有不同，比如view层可以和model层直接沟通，并没有经过Controller层，因为前端不像后端，前端需要考虑用户交互的问题，代码的实现上也会有不同。

后端每次都是通过唯一的url地址，在路由中将对应的新html页数据返回，返回后不关心也无法关心页面了，前端则是需要响应各种变化做对应的处理，完全的遵循mvc的模式其实并没有很适用。

最终演变来的问题是：

1. model层与view层通信问题，需要通过控制层隔离吗？还是直接通信，通信是单向还是双向？
2. 控制器需要完成哪些功能，是简单的关联性流程调度，还是更加复杂的处理？

MVP

于是在mvc各种实现之后，提出来了一个新的模式，就是mvp，它将model与view隔离，通过Presenter层进行沟通，用户的操作逻辑也都在Presenter层中。

三层定义：

1. Model层：提供操作数据的接口
2. View层：提供更新视图的接口，当用户有行为发生时触发事件
3. Presenter层：定义用户的交互逻辑与流程，但所有与数据操作和视图的更新都通过调用Model层与View层的接口实现，注册View层事件。

通过事件订阅模式解决层与层之间的强耦合。

这里其实已经能看到现在开发模式的雏形了，mvp把view和model抽象后只留下了接口，并且把业务逻辑全部封装到Presenter层中，但是此时的Presenter层需要做的事情有很多，它需要处理事件订阅，需要处理数据响应，以及复杂的业务代码，并不纯粹，而且体积非常庞大。

MVVM

这是我们现在使用了架构模式，他是三个部分：M - V -VM（ViewModel）；很多人可能会以为是4个部分。

在mvvm中，vm的处理是无形的，他将事件绑定，数据的响应式做成了一套规则体系，不需要在手动去处理数据源的变化订阅，当model的数据发生变化，vm会自动将其映射到view层，反之view的变化也会自动映射到model层的数据。

简单点来说就是由数据驱动的模式，将繁琐的部分都给剥离出去，开发者能更加专注的处理业务逻辑。

总结

由于本人并没有经历过mvc和mvp的时代，所以很多东西都是懵懂的，特别是view层和model层为啥会耦合，等我有机会了解了再来细说一下。

总的来说简单了解了三种模式后，可以看出这其实是应对不同时代的需求所衍生出的解决问题的方式，也许以后会有更好的模式也说不定，总之以目前的能力，浅尝即可。

感谢这篇文章：《从MVC在前端开发中的局限性谈起》

不知道是不是真正的出处，先贴上吧