简介:
MV框架又是为什么兴起的呢？它的出现，伴随着一些 Web 产品逐渐往应用方向发展，遇到了在 C/S 领域相同的问题：由于前端功能的增强、代码的膨胀，导致不得不做“前端的架构”这个事情了。经常有人质疑，在前端搞 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 操作只是附加
为什么需要MV*框架？
所以回到那个问题上，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 架构系统的开发效率，如果再有外围的管控平台，生产效率将真正踏进工业化的阶段。
到这个阶段，前端开发人员的出路是什么呢？我认为有两种。拿服装行业来对比，如果你要的是普通的，就使用工业手段批量生产，使用 MV*框架，做好架构和组件重用，做得快，细节不是很讲究。如果你想要更好的，有特色的，就需要名家设计，手工打造，非常精巧，高端大气上档次。所以，这也就代表着前端开发的两种发展方向。
摘自：web 开发者
