前端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架构系统的开发效率，若是再有外围的管控平台，生产效率将真正踏进工业化的阶段。

　　到这个阶段，前端开发人员的出路是什么呢？我认为有两种。拿服装行业来对比，若是你要的是普通的，就使用工业手段批量生产，使用MV*框架，作好架构和组件重用，作得快，细节不是很讲究。若是你想要更好的，有特点的，就须要名家设计，手工打造，很是精巧，高端大气上档次。因此，这也就表明着前端开发的两种发展方向。