主干命名空间惯例最佳实践

这是一个单一的问题，但如果这是一个好的做法，我会全力以赴。主干命名空间惯例最佳实践

基本上，让我们说我们有这个平凡的场景：

(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(); 

})();

所以......如果我们在一个小应用程序的工作，也许是好的，但在大尺寸应用程序时，它是确定抓住所有的应用程序进入一个自我调用一致的函数？或者你指出我的其他做法是什么？

来源

2014-08-27 andresmijares25

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

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

如果你是新来的骨干/ RequireJS我建议你下面的教程：

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

来源

2014-08-27 19:50:19

谢谢一个男人！ – andresmijares25 2014-08-27 19:59:50

不客气！ – 2014-08-27 20:56:59

@ andresmijares25你不想附加太多的全局应用程序对象，应该只存在于调试/开发模式btw的对象（在prod中需要它，你总是引用所需的应用程序对象（通过requirejs）它仅用于在浏览器中进行调试）。你真正需要的是一个'国家'模式。用RequireJS休息 - 路由到模块并创建视图/模型/收集 - 当去到一条新路线时，其中大部分将被释放用于垃圾收集。建立一个视图 - 子视图系统来确保你的DOM被正确清理也是一个好主意（删除一个视图并且它也会删除子视图） – 2014-08-29 11:46:05

如果你正在构建任何非平凡大小的主干应用程序，去与RequireJS。我会推荐他们的Sugar Notation。这种方法的好处：

降低依赖性问题的风险。如果脚本没有定义，您将无法使用它。有了全局对象，你偶尔会忘记定义一个脚本，但你不会注意到它，因为以前的脚本已经加载了它。然后，每25次页面中就有1次会失败，因为调用顺序变得混乱。这是可以想象的最糟糕的错误，你可以完全避免它。
无需污染在全球范围内与您的实例变量
清洁要求的理想

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

来源

2014-08-27 20:22:14 stakolee

主干命名空间惯例最佳实践

回答

相关问题