Backbone.js选型使用分析

    Backbone是一款很不错的轻量级的提供前端MVC模型编程的解决方案,其提供的Model,View,Controller等接口可以帮我们很清晰的从一大堆海量代码中解脱出来,Backbone本身就体积很轻有个4K-5K的样子,依赖也很少,只有一个underscroe,里面提供了一大堆数组操作还有模板解析的函数。

    我目前也在重构整个前端的代码,之前的代码因为公司初创的缘故,在宝贵的短期时间内要求上线的情况下,对模块划分是有一定欠缺的,部分代码还只是简单的面向过程编程的形式,考虑到日后公司第二阶段扩展的缘故,我目前要求用2周的时间把前端代码重构一番,其中就考虑过用Backbone.js,但经过前端系统预估后发现,用backbone对我们的工作可能并不会带来多大的好处。

    之前我可能会认为,有一个已经为你整理好模块形式的框架帮你去做你想做的重构不是很好吗,看起来是这样,但也要与公司业务还有系统规模结合起来,就像我的前端系统这样,我已经考虑到近10年的全部业务需求了,但总体系统来看是还不会到用backbone的地步,系统比较小,不会无所止境的扩大,单独把一些重用模块和业务模块抽象成对象,然后借助包管理和命名空间管理方式就完全可以解决我现在的问题了,用Backbone除了让我的代码跟多以外,实际上投入是大于产出的,公司扩招前端工程师以后,他们还要去了解Backbone怎么用,宝贵的时间显然又花费了很多,况且MVC是一种思想上的概念,如果把M V C划分清楚后,完全可以通过规范来自己形成这种思想架构,这样读起来也很容易,开发速度也会比较快,因为有了统一的模式规范,日后的管理也会容易,又因为使用requireJs来管理模块依赖,是可以应付这种情况的。

   所以我想表达的是,backbone的使用对于复杂的大型前端系统设计是一块瑰宝,但对于小步快跑的小型公司未必适合,所谓选型还要结合业务走为妙。

相关推荐