谈谈关于前端的MVC

Posted on |

记得最早说前端的MVC时，在大学里面教我们HTML老师是这样解释的， 在很早以前制作网页时充斥则诸如dreamware的网页制作（非开发）工具， 大部分的网页中都混杂了大量的嵌套在标签中的样式， css的片段，以及各种javascript脚本的片段。 所以在学校期间时的前端mvc就是html负责数据的展示，关于样式的控制全都交给css来处理，而页面中的逻辑处理，都交给javascript来完成。 这应该算是最早的关于前端的mvc的解释了。不过其实那个时候大部分web系统的逻辑处理还是交给服务器端程序来处理的。

再过了一段时间，SOA的概念慢慢盛行起来webservice,restful各种关于这些服务的开发框架如apache cxf慢慢入侵到曾经股如磐石的SSH解决方案当中，而随之而来的就是大量的逻辑代码都转移到了前端开发者的手中，记得那个是否领导是这样说的，用SOA的东西，我们可以只做一个后端服务，而客户端的形式可以随着需求不断的改变，不管是浏览器还是移动端都可以得到支持，当然这到现在也是算正确的。

而真正接触前端MVC是一年前看的那本叫做《基于MVC的JavaScript Web富应用开发》的书，那时候才发现原来前端开发还可以这样结构化和层次化，当然那个时候也已经有了诸如Backbone和Ember的解决方案，而那时候由于公司也刚成立不久，研发工作还处在极其混乱的过程中，像我这样的年轻程序员和老一辈的程序员在一起工作，由于我自己的开发习惯更加注重前端和用户体验的东西所以开发系统时如上面说的喜欢把后端做的更接口化，而大量工作是放在前端来做的，而稍大的程序员则更喜欢诸如SSH式的解决方案，也更习惯把前端的逻辑控制放在JSP中，所以那时候有一段时间大家都在讨论如何让公司的研发工作更加统一一点，无论是以java为主的后端开发，还是js系的前端开发。 当然java企业级开发的解决方案特别多，无论是自己搭建还是找一套现成的解决方案都是比较容易的， 但是前端开发要找到一个合适的解决方案就不是那么容易的一件事情，可能每一个做web软件开发的人都会写那么点js代码，甚至完全不动javascript的人也能比较轻松的通过在网上copy实现一段js功能，但是由于大量逻辑工作转移到前端，而每个人的前端开发水平有参差不齐，所以每个人写出来的代码基本都只有他自己能看懂。 也就是说一个项目有10个人做前端开发，就有10种完全不同的编码方式， 可以预见随着系统越来越复杂和庞大的情况下，在不久的将来系统将变得越来越不可维护。当然这种情况都是发生在这样的初创公司里， 所以为了能解决这种问题那时候就开始对前端MVC框架有了一些接触，而那个时候是选择的ember.js作为解决方案。 不幸的是由于那个时候大部分做前端开发的都是即做后端也做前端的人， 而ember.js的开发方式又显的过于超前了一点，所以做了一段预研后，公司并没有使用这一解决方案， 而是稍微规范了前端开发的编码风格。

不过也是由于上面的原因，我开始重新审视过去所做的前端开发工作。

  • 代码臃肿
  • 缺乏可测试性
  • 协同开发能力弱
  • 可维护性极差
  • 由于jquery导致的大量事件绑定与回调
  • 业务逻辑与dom操作混杂….

所以一句话就感觉就像是一陀狗屎一样。

如果是ember.js算是对前端mvc的一次初识，那么Backbone.js算是第一次的实践，这两个前端MVC框架中Backbone感觉更轻量级一点，而且由于和jquery的搭配使用所以更容易上手一点。两个框架都可以通过浏览器的hash实现路由功能，也可以使用html5的pushstate来实现，不过需要后端配合。 两个框架都使用前端模板引擎来绑定视图和数据，不过在这方面感觉ember.js的能力更加牛B一点，它是双向的数据绑定，Backbone则需要自己实现对model的监听来更新视图。例如如下的这种形式的代码片段一样，完整代码在这

1
2
3
4
5
initialize: function() {
  this.listenTo(this.model, 'change', this.render);
  this.listenTo(this.model, 'destroy', this.remove);        // NEW
  this.listenTo(this.model, 'visible', this.toggleVisible); // NEW
}

在模板引擎方面两个框架分别使用了第三方的前端模板系统Handlebars和Underscor。其它的如model层两个框架都做了对浏览器本地存储和rest接口的适配。总的来说两个框架大部分东西都大同小异。

这里我说说我觉得这两个前端MVC框架带来的一些好处， 代码层次更加清晰，协同开发性更好， 代码更加面向对象，当然可维护性也得到的很大的提高， 统一了每一个开发人员的编码风格等等， 但是却并没有解决所有的问题，如可测试性，依然不是很高， 部分代码中依然会混杂部分的dom操作。 不好的方面则在于在一些小的功能块显的有点大才小用了， 反而增加了一些复杂度， 所以说前端的MVC框架也并不是万能的解决方案， 更适合那些CRUD的系统实现同时后端应该是rest风格的接口设计。

上面部分算是对之前学习Ember和Backbone的一些总结，在学习这两个框架的过程中，学到了许多新的是思想

下面要说的主题，我们先来看一个例子:

这个例子实现了一个简单的购物车。 查看实际运行效果我们大概可以得出一下几个结论：

  • 模块化命名空间，依赖关系组织
  • 自动的数据双向绑定， 这该较少多少代码量
  • 业务逻辑完全不包含dom操作，意味着可测试行
  • 非侵入的事件绑定
  • UI区分与Controller的职责划分
  • 代码量更少了，因为只关注了业务逻辑

这就是来自Google的前端JS框架Angular，当然今天写这边博客时，我也只算是对Angular有一个初步的认识， 但是当第一次看到它时，我就深深的被它这种简洁性吸引，同时它的核心特性如：MVC，模块化，依赖注入， 自动化双向数据绑定， 语义化标签等特性都显的那么个性鲜明。 用别人的一句话：编写web的应用的过程应该更像是创作，Angular就给了我这样的感觉。

而且最重要的一种感觉就像是开篇文章所说的老师在上课时教我们的那样，在“制作网页”中html负责数据展示，CSS控制页面的样式， 而javascript则实现页面的逻辑。 当然现在的网页制作有了一个更专业的名字叫前端开发。 从最初的mvc概念到后面的Ember和Backbone，再到Angular给我的感觉就像是一种 从简单到复杂再到简单的一个过程

这篇文章算是对我Angular深入学习的一份开篇