关于backbone看法

自己正在学习backbone中，看到了师父写的这篇文章，感觉受到了启发。好东西当然要分享。

---

一、准备阶段1.1 框架选型

随着对MV*架构模式的逐步理解，越来越发觉对于一般的业务场景，mvvm是前端架构的不二选择。在我所了解的框架范围内，与mvvm架构模式最贴合的框架只有angular，无论是双向数据绑定、指令，还有强化的html标签，angular提出的很多新概念都像是为mvvm理论量身定做的一套外衣。很可惜angular对ie8的支持不太友好，兼容ie8的angular插件也非常稀缺，对于国内环境，ie8仍然占有较大的市场份额，无奈之下只能转向轻量级的backbone。

1.2 官方文档vs电子书

通过阅读backbone的官网简介，总结下backbone特点（并非优点）：

• 提供了基本的MVC结构，可以做到业务逻辑与视图的分离（MV*框架最基本的功能）
• 内置支持restful风格的API（做过项目后会发觉，内置的那套基本没什么用，自定义会更合适）
• 路由的支持（大部分MV*框架也都支持，也不是亮点）
• 方便与第三方插件集成（因为backbone太轻量了，对于插件没什么要求，这勉强可以算优点）
• 兼容ie8（对比其他MV*框架，感觉这是唯一的优点，也是选择它的理由）
• 粗粒度的单向数据绑定（缺点，每次更新视图，都只能全部更新，当然你可以自己写局部更新，会比较繁琐）
• 太轻量了（缺点，连angular这种重量级的框架写法都会五花八门，backbone这种就更别提了，新手根本无法驾驭它写出优良的代码）

由于backbone功能单薄，无法形成固有的mvc或是mvp模式，但是为了让它变得好用，我们可以尝试增强它的功能，让它更接近我们想要的mvvm框架。mvvm框架最大特点是：双向数据绑定，于是通过google：backbone data binding，找到了以下几个backbone插件：Backbone.ModelBinder、Rivets.js、Backbone.Stickit。通过测试发现Rivets.js很好用，可惜不兼容ie8，ModelBinder配置不够灵活，于是Stickit成为最佳选择。

关于框架的学习，我的思路是这样的：官方文档是一定要看的，但是没必要从头看到尾，官方开头那部分介绍是一定要看的，那里会告诉你框架是什么样的，有什么特性，而具体的API只要看能反应出框架特性的那几个API就够了，其他的都是用来查的。有些API不用查，你也知道它肯定有，就像你学完java后学C++，你知道C++里肯定有for循环。
只看官网文档是远远不够的，文档只是告诉你可以这样用，但是没有告诉你该不该这样用，所以当你大体了解了一个框架的基础知识后，应该找一本名叫《xxx框架最佳实践》的电子书，了解下怎么用才合理，对于轻量级的框架尤其如此。

学计算机知识，一个wiki百科就够了（要翻墙），千万不要看国内某百科，连自己贴吧的内容都可以当参考文献，实在是太不靠谱了。

二、实践阶段

准备阶段做得越多，实践起来就越轻松，项目需求分析阶段，开发人员的时间如果用来做技术调研、框架选型、编写demo、测试性能、编写非业务组件等工作，时间还是会比较紧张的。
在了解了backbone的特性，阅读完backbone最佳实践后，开始真正编写项目，一切都很顺利，只踩到两个坑：性能、复杂界面的逻辑处理，而这两个坑是由mvvm的基因决定的。

mvvm的双向数据绑定可以让开发变得非常便利，但同时也带来了两个问题：

• 为了将model与dom中的元素一一对应进行绑定，即便最简单的界面，也会消耗大量性能，当需要一次性加载大量数据时，性能问题就会凸显。
• 数据绑定是基于观察者模式构建的，当界面中存在多个组件，且组件间有复杂交互时，代码很难跟踪，调试会变得非常困难，当修改了某个model时，你无法清晰的了解后面会发生什么。

针对mvvm的缺点，以下业务场景是不适合的：

• 由于极端的用户体验要求，需要一次性渲染大量数据，不能分页的场景。
• 组件多且交互过复杂的场景。

据说angular2.0也倾向单向数据流，估计也是考虑到这个原因，react+flux也推崇单向数据流，也许这是一种趋势。但对于一般的业务场景来说，双向数据绑定还是非常实用的，所以具体采用什么方案还是要结合具体的业务场景。

三、总结

• backbone.js是一个功能单薄的框架，它需要其他插件的辅助才能变得好用。
• 没有了解过xxx最佳实践，就不要轻易在项目里使用，不然往往会得到xxx不好用的错误结论。
• 没有一个模式永远是最佳的，只有适合业务场景的模式才是最佳模式。