说实在的,我不以为MVC,MVVM这些框架有什么难的,直到我想写一篇文章去系统的阐述它们。我遇到了如下几个问题,1.不一样的文章说的南辕北辙 2.没有一个清晰的大纲和框架分类。因此我查了不少的材料,但愿能从本身的角度上用通俗的语言阐述前端框架的演变。
演变目的: 用简单的方法处理愈来愈复杂的View层
在最开始的时候,View层是很简单的,甚至都没有什么画面;而随着信息时代的发展,它变得愈来愈复杂。如今,前端页面会有不少复杂的交互逻辑和用户体验,若是还使用以前老的框架,对View层的操做就会难以维护,这就是前端框架要不断演变的主要缘由。html
框架分类:讨论框架必定要结合应用场景和历史背景
上世纪70年代,MVC诞生。最初是应用在GUI程序(图形界面程序)上,而不是WEB程序上——对于这种MVC,咱们称之为经典MVC。后来,在WEB程序上的MVC都是经典MVC的变体;并且,WEB程序上后端MVC和前端MVC也会有些许区别。所以,不区分应用场景和历史背景,就把经典MVC和WEB MVC混作一团是很是不负责任的。前端
另外,无论MVC,MVP,MVVM以及它们诸多的变体MVX,本质上都是三层的结构。git
回想咱们在文章第一部分就着重提到的,演变的最终目的就是为了适应愈来愈复杂的View层,让咱们一直记着这句话来看下面的内容。github
第二部分已经提到过了,由于MVC变种众多,不结合应用场景和历史背景的讨论都是耍流氓。后端
在上世纪70年代,由于没有操做系统和消息循环,甚至鼠标的光标都须要咱们的UI系统来自行绘制,因此这时候用户的输入是由Controller来得到的[1]。Controller得到用户的输入以后,去调用相应的Model修改数据,同时修改View响应用户的输入。Model的数据修改以后,会通知相关的View。View监听Model,当收到通知后,就修改样式。设计模式
调用关系以下[2]:前端框架
咱们能够看到,WEB MVC和经典MVC本质上是同样的,一样都拥有了Controller去修改Model的调用关系。可是,它们之间有两个区别:架构
优势:mvc
缺点:框架
感谢前端的前辈们,咱们并无在MVP阶段多作逗留,而是大步进入了MVVM阶段。其实MVP和MVVM的主要区别就是在因而否有双向数据绑定。有兴趣的能够看《浅析 MVC, MVP 与 MVVM之间的异同》自行了解。
在3.2咱们实现了一个简单的MVC,设想一下,如今页面上不是只有一个按钮,而是有1000个按钮,每一个按钮还要操做不一样的DOM对象,由于MVC是没法组件化的,这时View的逻辑就会变得很是的复杂和难以维护。为了解决这个问题,MVVM就应运而生了。
用户与View交互,触发用户事件;View根据事件类型调用ViewModel中对应的响应逻辑;而后ViewModel中的响应逻辑在作完适当处理后,会去调用Model层的接口;接口的调用执行,致使Model层数据的变化,进而触发相应的数据改变事件;事件又被ViewModel模块监听到;拿到新的Model数据,ViewModel中的展现逻辑会去修改ViewModel中的状态数据;ViewModel中状态数据的改变,最终引发View的状态变换,完成了此次对用户事件的响应。
优势:
缺点: