前端的复兴之路--MV*

前端的近代历史，近代变更，这个话题就宛如古代后宫剧-一波三折
简述一下CSS,HTML和ES的历史吧

近代史

时间	事件
1990	HTML诞生， 随之出现第一个叫Mosaic 的浏览器
1994.7	HTML 2.0 规范发布，网景公司成立，W3C成立
1995	网景设计出js，JavaScript诞生
1996	css1.0出现，js的诞生后续引发了第一次浏览器大战
1997	W3C推出了HTML3.2，ES1.0，HTML4.0
1998	W3C推出了css2.0，ES2.0
1999	第一次浏览器大战结束，IE完胜，前端进入梦魇的时期，ES3.0，HTML4.01
2001	CSS3.0
2004	FireFox开启第二次浏览器大战
2008	HTML5.0
2011	ES5.0
2015	ES6.0
2017	第二次浏览器大战结束，IE落败，FireFox站稳脚，Chrome胜利

动态技术

技术上，JavaScript 诞生之后，为了使得 Web 更加充满活力，不再仅限于对DOM样式的更改，以 PHP、JSP、ASP.NET 为代表的动态页面技术相继诞生，但是动态技术仍无法挽救前端的微弱地位。

AJAX

2005年AJAX技术诞生，这种异步相应局部的刷新立刻掀起一阵前端的狂潮，这种革命性的技术，颠覆了用户体验。随着 AJAX 的流行，前端慢慢走向欣欣向荣的局面。

Node.js

Chrome浏览器的V8引擎出现同时促就了基于事件循环的异步 I/O 框架–Node.js的诞生，前端也能写后端的东西，前端的生态系统得到了完善，同时NPM 作为 Node.js 的包管理系统首次发布。让模块化开发有了雏形，前端正式兴起，前后台开始分离

MV* 架构

随着HTML5的火爆，前端慢慢被重视，随之前端逻辑越来越复杂和难以维护，前端引进了后端的架构思想（ MV* ）

M	Model 数据层
V	View 视图层

随之诞生了设计模式有MVC=>MVP=>MVVM

C	Controller 控制器，业务逻辑，互动：一种是通过 View 接受指令，一种通过Controller 接受指令。
P	Presenter 提出者，互动：View 与 Model 不发生联系，都通过 Presenter 传递。
VM	ViewModel 视图模型，互动：双向绑定（data-binding）：View的变动，自动反映在 ViewMod

MVC

View 传送指令到 Controller
Controller 完成业务逻辑后，要求 Model 改变状态
Model 将新的数据发送到 View，用户得到反馈

优点：

把业务逻辑和展示逻辑分离，模块化程度高。且当应用逻辑需要变更的时候，不需要变更业务逻辑和展示逻辑，只需要Controller换成另外一个Controller就行了（Swappable Controller）。
观察者模式可以做到多视图同时更新。

缺点：

Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，应用逻辑正确性是无法验证的：Model更新的时候，无法对View的更新操作进行断言。
View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

MVP

各部分之间的通信，都是双向的。
View 与 Model 不发生联系，都通过 Presenter 传递。
View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

优点：

便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter应用逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。
View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。

缺点：

Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

MVVM

基本和MVP一样，唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。

优点：

提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。

缺点：

过于简单的图形界面不适用，或说牛刀杀鸡。
对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。