Backbone命名空间约定最佳实践

时间:2014-08-27 19:33:57

标签: backbone.js namespaces

这是一个单一的问题,但如果这是一个好的做法,我全神贯注于这个事实。

基本上,我们说我们有这个微不足道的情景:

 (function(){

   window.App = {
    Models: {},
    Collections: {},
    Views: {}
   };

   App.Models.Person = Backbone.Model.extend({});
   App.Views.PersonView = Backbone.View.extend({});
   App.Collections.PeopleCollection = Backbone.Collection.extend({});


   var person = new App.Person(); 

 })();

所以...如果我们正在开发一个小应用程序,也许没问题,但是在处理大型应用程序时,可以将所有应用程序都集成到一个自动调用的函数中,或者其他什么做法你们指出我了吗?

2 个答案:

答案 0 :(得分:2)

我们决定使用RequireJS来组织我们庞大的代码库。结果很棒。

它鼓励模块化和清洁的结构。我们最终没有一个window.Whatever全局可见的有状态麻烦制造者,我们喜欢它。

如果您是Backbone / RequireJS的新手,我建议您使用以下教程:

http://backbonetutorials.com/organizing-backbone-using-modules/

答案 1 :(得分:2)

如果您正在构建任何非平凡大小的Backbone应用程序,请使用RequireJS。我推荐他们的Sugar Notation。这种方法的好处:

  • 减少依赖问题的风险。如果未定义脚本,您将无法使用它。对于全局对象,您偶尔会忘记定义脚本,但由于之前的脚本已经加载了脚本,因此您不会注意到它。然后,每25次中有1次您的页面将失败,因为呼叫顺序混乱。这是可以想象的最糟糕的错误,你可以完全避免它。
  • 无需使用实例变量污染全局范围
  • 清洁需要理想

这意味着您保存目录结构的命名空间。如何定义代表类的变量更像是“绅士的协议”。