backbone.js选型使用分析

本文探讨了在小型公司环境下使用Backbone.js进行前端代码重构的适用性和局限性。通过对比现有代码结构与业务需求,文章指出Backbone虽然提供MVC模型编程解决方案,但在系统规模较小且业务需求相对稳定的情况下,采用规范化的模块管理和命名空间管理方式足以应对重构需求,相较于引入Backbone带来的额外投入,这种方式更符合成本效益。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

 

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

 

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

 

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值