这个博客已经过去了很久……

不过,你可以通过以下方式找到我

现在的位置: 首页 > 谈前端 > JavaScript > 正文
前端MVC框架的意义
2013年10月23日 JavaScript ⁄ 共 3101字 等你评论

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

前端MVC框架的意义

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

  早期前端都是比较简单,基本以页面为工作单元,内容以浏览型为主,也偶尔有简单的表单操作,这个时期每个界面上只有很少的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*框架,做好架构和组件重用,做得快,细节不是很讲究。如果你想要更好的,有特色的,就需要名家设计,手工打造,非常精巧,高端大气上档次。所以,这也就代表着前端开发的两种发展方向。

友荐云推荐
×