主幹命名空間慣例最佳實踐

這是一個單一的問題，但如果這是一個好的做法，我會全力以赴。主幹命名空間慣例最佳實踐

基本上，讓我們說我們有這個平凡的場景：

(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

主幹命名空間慣例最佳實踐

回答

相關問題