Backbone.js 的最佳應用場景有哪些？#zhihu#

這段時間，想再次瞭解下backbone js的相關知識，就把一些認爲不錯的拿過來了；

新版的有道筆記 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。
• 更新慢。

整體來講 Backbone 還很輕，框架很漂亮可是有些細節還比較粗糙。用以前要作好對 Backbone 進行大量擴展甚至 Hack 的準備。

做者：pw