前端MV*框架的意义

经常有人质疑，在前端搞MV*有什么意义？也有人提出这样的疑问：以AngularJS，Knockout，BackBone为代表的MV*框架，它跟jQuery这样的框架有什么区别？我jQuery用得好好的，有什么必要再引入这种框架？

回答这些问题之前，先要理清一些历史，前端从什么时候开始有框架的？

早期前端都是比较简单，基本以页面为工作单元，内容以浏览型为主，也偶尔有简单的表单操作，这个时期每个界面上只有很少的JavaScript逻 辑，基本不太需要框架。随着AJAX的出现，Web2.0的兴起，人们可以在页面上可以做比较复杂的事情了，然后前端框架才真正出现了，以jQuery为 代表，针对界面上常见的DOM操作，远程请求，数据处理等作了封装，也有专注于处理数据的Underscore，严格来说，这些都不能算框架，而是算库。

库和框架是有一些区别的：库是一种工具，我提供了，你可以不用，即使你用了，也没影响你自己的代码结构。框架则是面向一个领域，提供一套解决方案， 如果你用我，就得按照我的方式办事。按照这个定义，jQuery和Underscore都只能算是库，ExtJS和dojo算框架。

MV*框架又是为什么兴起的呢？它的出现，伴随着一些Web产品逐渐往应用方向发展，遇到了在C/S领域相同的问题：由于前端功能的增强、代码的膨胀，导致不得不做“前端的架构”这个事情了。

很多做后端开发的人对前端架构很不屑，认为前端只是很薄的一层东西，做架构干什么？什么，不但要搞架构，还要搞MVC？Java Struts的MVC中，整个前端都只能算是View而已，你还要在这个View里面划分模型和控制器等其他东西？他们中的多数对这个很不屑，但Web前 端随着复杂度的增加，很多地方跟客户端已经没有本质区别了。

jQuery的思维方式是：以DOM操作为中心
MV*框架的思维方式是：以模型为中心，DOM操作只是附加

所以回到那个问题上，jQuery满足了你的业务需要，你还有什么必要引入MV*框架？

这个是要看产品类型的，如果是页面型产品，多数确实不太需要它，因为页面中的JavaScript代码，处理交互的绝对远远超过处理模型的，但是如果是应用软件类产品，这就太需要了。

长期做某个行业软件的公司，一般都会沉淀下来一些业务组件，主要体现在数据模型、业务规则和业务流程，这些组件基本都存在于后端，在前端很少有相应 的组织。在以往的经验里，他们是有做MVC的，也尝试做了一些界面组件，但做法比较过时，比如说使用JSF或者GWT这样的方式。

JSF的问题是什么？它的问题并不在于界面跟逻辑混合，所谓的纵向切分组件，Polymer这种纯前端框架也是这么切分的，它问题在于组件的生成和 渲染不在同一个地方。所以，逻辑代码的位置很尴尬，如果这个界面简单还好说，复杂起来就很麻烦了，就是很多明明是前端逻辑代码，却需要通过后端去生成。

GWT这种方式相对要好一些，它的问题是留给UI调节的余地太小了，比较缺乏灵活性。

这类基于某种服务端技术的组件化方式有一些局限性，比如它较大程度限制了前端的发挥，在早一些的时候，这种方式可能还不错，但是现在随着时代发展， 用户对前端用户体验要求越来越高，需要我们把很大一部分精力继续放回前端来。JSF等方案的另外一个问题是绑定了某种服务端环境，很难切换到另外一种后端 上，如果碰上要用Hybird方式开发，想复用一些前端逻辑，几乎毫无可能。

那么，我们看看纯前端的框架，看看都是怎么解决这些问题的。以Google为例，它推出了两个框架，Polymer和Angular，而且处于并行发展的阶段，这两者理念还有不小的差别，给不少人带来了困惑。

Polymer切分组件的方式有点类似JSF，它跟HTML5标准中的Shadow DOM和Element有很大联系，这种切分组件的方式非常直观，每个组件都是端到端的，包含UI和逻辑，直接放置到某个界面上就能用，这种方式很容易被 业务开发人员接受，但里面的时序比较难处理。

比如说，有两个组件，里面各包含一个下拉框，有数据的联动关系，因为它们处在两个不同的组件里，联动的处理代码就很难写，考虑到组件的特点，要尽量 隐藏自己的内部实现，所以从外部获取组件内部的某个元素要绕一层，而组件不能依赖其他外部的东西，所以到最后只有通过事件去实现，这个联动代码写好了应当 放在哪里，也是个大问题。我们的例子仅仅是这么简单，就要绕这么个大圈子才能保证时序，如果场景比较复杂，非常难以控制。

如果同样的组件在某个界面被复用多次，数据的一致性也很难保证，设想一下某个界面存在两个一样的下拉框，分别处于不同组件中，两者的数据都需要分别 去加载，这个过程是有浪费的，更严重的是，如果这个下拉框对应的数据有更新，很难把每个实例都更新一遍，这个处理过程是非常麻烦的。

Angular框架处理问题的方式跟它有所不同，它是水平分层，所有这些数据访问逻辑都跟UI彻底分离，所以可以很轻松地把这个逻辑代码写出来，这么一来，前面所述端到端的组件就彻底退化，变成只有界面展现了。

看看刚才碰到的两个问题，第一个，模型代码按照业务领域进行划分，获取的数据放在两个不同的数组，然后通过双向绑定跟UI产生关联，如果UI上一个 下拉框选中项发生变更，只需要监控这个取值项，然后更新另一个下拉框的取值列表即可，完全不需要绕弯子。即使这两个处于不同模型中，也可以用类似后端的方 式，采用事件总线等机制去完成通信。

第二个更简单了，复用的组件其实只有UI，也就是说，只有UI是多实例的，模型其实只有一份，比如说一个地区的树形结构，即使一个界面上同时有维护 和使用两种功能，都可以共享同一份模型，当维护这边对数据进行了更新，就实时反馈到模型中，然后由双向绑定再把这个模型同步到界面上的使用方去，整个过程 清晰可控。

从协作关系上讲，很多前端开发团队每个成员的职责不是很清晰，有了前端的MV*框架，这个状况会大有改观。MV*框架的理念是把前端按照职责分层，每一层都相对比较独立，有自己的价值，也有各自发挥的余地。

为什么多数做互联网前端开发的同学们感受不到MV*框架的重要性呢，因为在这个协作体系里，Model的这一块不够复杂，在传统软件领 域，Model的部分是代码最多的，View的相对少一些，而互联网领域里，基本是相反的，所以Model这块沦为附加，如果主要在操作View和 Controller，那当然jQuery这类框架比较好用了。

所以，经常看到有互联网产品的同学们讲前端MVC，但举例的时候，都比较牵强，很多时候，他们举出来的那个Model，其实都不能算真正的Model，而是在操作View的过程中一些辅助的模型，真正的Model是贯穿前后端的。

归根结底，前端MV*框架带来的是一整套工作流程的变更，后端工程师也可以编写前端的模型代码，把它跟后端彻底打通，交互工程师处理UI跟模型的互 动关系，UI工作人员可以专注、无障碍地处理HTML源码，把它们以界面模版的形式提供给交互工程师。这一整套协作机制能够大大提高B/S架构系统的开发 效率，如果再有外围的管控平台，生产效率将真正踏进工业化的阶段。