Backbone.js 的最佳应用场景有哪些？

浏览数：31 / 时间：2015年06月09日

新版的有道笔记 Web 版（http://note.youdao.com）也使用了 Backbone。就像其他答案回答的，Backbone 最适合的应用场景是单页面应用，并且页面上有大量数据模型，模型之间需要进行复杂的信息沟通。Backbone 在这种场景下，能很好的实现模块间松耦合和事件驱动。其他适用产品还有微博，网易微博的前端设计也是和 Backbone 类似的一个结构。

Backbone 的优点和一些经验 Tip：

View 的划分将页面上的视图元素解耦，粒度细化。View 间通过事件和 Model 通讯，避免了 DOM 事件的滥用。
Model 和 Restful 的通讯方式对于后端人员非常友好。
MVC 架构清晰，我有个常年写 Java 没写过 JS 的同事看 Backbone 很快就了解了整体设计，虽然这时候他还是不会写 JS。
Collection/Model 抽象了以前杂乱的 AJAX 请求，CRUD 请求变得非常非常方便。
强烈建议 View -> Model 单向依赖，世界会美好很多。
配上一个模块化加载器例如 SeaJS 会很爽。

Backbone 的一些缺点，或者说一些尚未实现的 Feature：

Model 层比较简单，如果要支持 One-To-One 或者 One-To-Many 等复杂数据关系时有些力不从心。还有一个 Model 只能属于一个 Collection 这个设计，页面复杂的时候会很受局限。例如这个问题： http://www.zhihu.com/question/19843899 （补充：Backbone.Relations 插件是这个问题的一个解决方案https://github.com/PaulUithol/Backbone-relational By zjhiphop）
同上，Model 只有基本的 CRUD 操作，不能很好的扩展，Backbone.sync 方法写的不太灵活，要想扩展就得重写 sync 方法。
View 层没有很强的 Page 管理机制，比如通过 URL 切换改变整个页面时，页面上尚存的 View 如何处理？直接销毁的话，是否要销毁关联的 Model、Collection？Cache 住？如何管理 Cache？
内存管理需要比较小心，缺乏机制避免创建重复 Model。
extends override 父类方法的时候得写一串的 SuperClass.prototype.someMethod.apply 什么的，就不能实现个 _super 方法么……
对调试非常不友好。
作者有代码洁癖（也是加分项），this.$el 大家呼唤了这么久才加上，估计今生也看不到 this._super。
更新慢。