简单了解 前端构架模式MVC与MVVM

本文主要讲解MVC和MVVM两大常见的前端架构模式，进入正题之前，有必要了解一下前端的发展历史和某些关键概念。

前端构架模式演变历程

1.最早期，将HTML页面置于Web服务器中，根据用户请求的URL不同，返回对应的HTML页面到浏览器以渲染页面。 存在局限性：HTML是静态页面，如果要针对不同的用户显示不同的页面，需要为不同用户准备不同的HTML文件，显然难以完成。

2.利用C、C++这些编程语言，直接向浏览器输出拼接后的字符串，这种技术被称为CGI：Common Gateway Interface。服务器就可以针对不同的用户，动态生成不同的html文件。 存在局限性：复杂的页面难以通过拼字符串得到。

3.动态HTML的方式：ASP、JSP和PHP。如一个asp文件就是一个HTML，需要替换的变量用特殊的<%=var%>标记出来了，再配合循环、条件判断，创建动态HTML就比CGI要容易得多。存在局限性：更新页面内容，唯一的方法就是重新向服务器获取一份新的HTML内容

4.JavaScript被引入到浏览器。

• 第一阶段，直接用JavaScript操作DOM节点，使用浏览器提供的原生API对页面进行一些修改。；
• 第二阶段，由于原生API不好用，还要考虑浏览器兼容性，jQuery横空出世，以简洁的API迅速俘获了前端开发者的芳心；
• 第三阶段，MVC模式，需要服务器端配合，JavaScript可以在前端修改服务器渲染后的数据。
  现在，随着前端页面越来越复杂，用户对于交互性要求也越来越高，想要写出Gmail这样的页面，仅仅用jQuery是远远不够的。同期，MVVM模型应运而生。
• 第四阶段，数据驱动视图和Flux模式。数据变成了单向传递的，这就避免了双向绑定时局部状态和APP全局状态冲突的矛盾。

经过几十年的发展和演变，从MVC架构模式到MVVM架构模式，出现了诸多的实现方式，但本质是不变的。其核心是关注点的分离，需要将不同的模块和功能分布到合适的位置中，减少依赖和耦合。

框架、设计模式、软件架构和架构模式

框架（Framework）

一个系统的可重用设计，表现为一组抽象的可交互方法。它就像若干类的构成，涉及若干构件，以及构件之间的相互依赖关系、责任分配和流程控制等。

比如，C++语言的QT、MFC、GTK，Java语言的SSH、SSI，PHP语言的Smarty（MVC模式），Python语言的Django（MTV模式）等。

设计模式（Design Pattern）

一套被反复使用、多数人知晓的、经过分类的代码设计经验总结。其目的是为了代码的可重用性、让代码更容易被他人理解、保证代码的可靠性。

比如，工厂模式、适配器模式和策略模式等。

软件架构（Software architecture）

一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图，软件体系结构是构建计算机软件实践的基础。

架构模式（风格）

也可以说成框架模式，一个架构模式描述软件系统里基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。

一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式就属于架构模式，还有MTV、MVP、CBD和ORM等。

补充： 框架 vs 设计模式

框架与设计模式相似，但根本上是不同的。

设计模式是对某种环境中反复出现的问题及解决该问题方案的描述，比框架更加抽象；

框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示；

设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。

可以说，框架是软件，而设计模式是软件的知识。

MVC

MVC（Model View Controller），是Model（模型）－View（视图）－Controller（控制器）的缩写。MVC不是框架，不是设计模式，也不是软件架构，而是一种架构模式。MVC的出现是为了让应用的业务逻辑、数据和界面显示分离的方法来组织代码。

MVC允许在不改变视图的情况下改变视图对用户输入的响应方式，用户对View的操作交给了Controller处理，在Controller中响应View的事件调用Model的接口对数据进行操作，一旦Model发生变化便通知相关视图进行更新。

模型、视图和控制器

MVC把软件工程分为三部分：模型、视图和控制器。这三者各有分工：

• 视图（View）：负责图形界面展示。一个View一般都对应着一个Model，可以读取或编辑Model。
• 模型（Model）：负责在数据库中存取数据，以及对相应数据的操作。它的数据被View所使用，View 和 Model 应用了观察者模式，当Model发生改变时，它会通知视图作出对应的改变。
• 控制器（Controller）：是 View 层和 Model 层的纽带，它主要负责用户与应用的响应操作，当用户与页面产生交互的时候，从 View 读取数据，控制用户输入，并向 Model 发送数据。Controller的存在是为了让视图和模型能同步。Controller本身不输出任何内容，也不做任何处理，它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示返回的数据。

前端MVC优缺点

优点：

1. 耦合性低；
2. 重用性高；
3. 部署快；
4. 可维护性高；
5. 有利于软件的工程化管理

缺点：

1. 视图对模型数据的低效率访问；
2. 视图与控制器之间过于紧密的连接；
3. 简单的界面如果严格按照MVC去开发会增加结构复杂性，降低运行效率，并且不适合中小型项目。中小型项目中使用MVC会得不偿失，增加项目复杂度。
4. 没有明确的定义，它的内部原理比较复杂，所以要完全理解MVC需要花费很多时间；
5. 在前端开发领域中，MVC还拥有一个致命的缺点——数据流管理混乱。随着项目越来越大、逻辑关系越来越复杂，就会明显发现数据流十分混乱，难以维护。

MVC组件运行流程

程序启动，首先进入控制器，查看是否需要操作模型的数据，并控制进入对应的视图，视图则去对应模型中获取数据显示到视图中。

在前端开发的应用中，一个事件的发生需要经历以下几步：

• 用户与应用产生交互。
• 事件处理器事件被触发。
• 控制器从模型请求数据，并将其交给视图。
• 视图呈现。

用户操作视图，触发事件以发起用户请求，控制器接受请求并联系模型处理数据，而后控制器控制进入对应的视图，模型告知视图有数据更新，视图获取模型层数据并呈现。

MVVM

Model-View-ViewModel的缩写，表示“模型-视图-视图模型”，本质上还是MVC的改进版。其设计思想是关注Model变化，让MVVM框架去自动更新DOM。MVVM要求View不能和Model直接通信。

MVVM 的核心实现是由 ViewModel 层实现数据绑定，它的核心思想是分离，也就是通过 ViewModel 让 View 层和 Model 层解耦（将视图 UI 和业务逻辑分开），这样有什么好处呢？

初衷是想让设计师专注 View 层的设计和编写，软件工程师专注 Model 层的业务逻辑编写。目前更多是因为ViewModel 可以取出 Model 的数据同时帮忙调整View 层（因业务逻辑改变而导致展示内容改变）。

MVVM与MVC最大的区别

MVVM实现了View和Model的自动同步，也就是当Model的属性改变时，我们不用再自己手动操作Dom元素，来改变View的显示，而是改变属性后该属性对应View层显示会自动改变。

这也是AngularJS的核心，它实现了数据绑定（Data Binding），将原来MVC中的C（Controller）用VM（ViewModel）来取代，相当于对MVC做了拓展。目前MVVM的前端框架有Angular、Vue、Backbone.js和Ember等。

以下在Vue中实现数据绑定：

MVVM优点

MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点：

1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
4. 可测试。界面素来是比较难于测试的，测试可以针对ViewModel来写。