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

01-04

使用 MVC 對於網站開發有幫助嗎?

2016 年補充:

經提醒，現在的有道雲筆記已經不是 Backbone 了。所以說，技術的選型，除了要看 contributor 的努力之外，還要考慮歷史的進程。

---

新版的有道筆記 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 的準備。

Backbone.js 的適用場景非常廣，無論是 Web-Page 還是 Web-App 都可以應用，但最合適的還是大型的 Web-App，對於中小型項目來講 Backbone.js 的 MVC 結構還是有點臃腫了，用不好很容易 over design。Backbone.js 是非常典型的 MVC 框架，但是相對於傳統的 server 端 MVC 來講還是有一些特殊的地方的。

首先 Backbone 中的幾大核心組件 View、Model、Collection、Router 中並沒有 Controller。其實 v0.5 以前是有 Backbone.Controller 這個東西的，但由於做的根本不是 C 的事情，這個名字又太具有迷惑性了，後來改名叫做 Backbone.Router。而真正的 C 其實是 Backbone.View，但這個 View 其實是部分的 C（還有一部分在 Backbone.Router 中） + 部分的 V，由於前端的模板功能有限，很多應該在 template 中做的事情不得不被拿到 Backbone.View 中來實現。

其次，由於 MVC 的概念中認為 V 其實是永遠不知道用戶輸入（滑鼠、鍵盤事件等）的，C 是輸入和 V 之間的連接，但在瀏覽器中這點其實是實現不了的，V 就是 HTML，而用戶輸入是基於 HTML 頁面的，所以你可以忽略用戶輸入，把所有事件都導入到 C 去處理，但不代表 V 不知道這件事情。所以前端的 MVC 多少是對傳統的 MVC 模型做了些改變的實現，近些日子更多的人轉向 MVVM 就是這個原因。

Backbone.js 的優點：

1. 代碼質量比較高，通讀一遍還是能學到不少東西的。

2. 只做框架該做的事情，不做高大全的東西。所以很容易和其他的工具或框架整合。比如有人搞了 Bakcbone.js + Knockout.js 的 Knockback.js。

3. 分層的結構很清晰，使得前端工程在擴展性和維護性上都可以進行有效控制。

Backbone.js 缺點:

1. Model 結構比較簡單，如 @pw 所述，多對多、但對多的數據模型很難搞，用對象做屬性也不行。

2. 內存控制，View 很容易產生 memory leak 的問題，不過這也和代碼的質量有關係，近期的更新有一些是針對這方面的。

to @pw：

我覺得 Sync 寫的簡單並不算缺點，源碼里寫明了這部分要根據具體業務需求重載掉的，很容易進行擴展。

P.S. 今年下半年更新比較緩慢，目前停留在 0.9.9，坊間傳聞是在憋大招，1.0 會有驚喜。

P.S. 豌豆莢 PC 客戶端 2.0 全部是使用 Backbone.js 框架開發的。

其實，對於這種客戶端的MVC框架，最佳的應用場合是SPA，即單頁面應用，也有很多其他的替代解決方案，和Backbone很相似的1個框架叫做Spine，不依賴於UnderScore，代碼量也相對較小，只不過兩者在MVC的封裝上思路稍有不同。具體的參考網址如下：

http://maccman.github.com/spine/

http://maccman.github.com/spine.tutorials/

國內使用Backbone.js比較經典的應用就是豆瓣說。正如其名字，Backbone起到了骨骼的作用，我們使用它的自由度很大。對於傳統網站，可以說使用不使用關係不是太大，但是對於heavy js的web 站點、app，又或是RESTful為主架構的網站，其數據從後台獲取後需要在前端渲染，此時類似於Backbone這樣的MVC架構的前端就會使開發變得尤為簡單方便。

對於重度javascript應用，特別是項目的前端開發參與人數比較多的時候很有用處

我們公司的一個企業協作的項目，重度javascript，單頁面，沒有用到mvc，只是用到了jquery, 開發進度很慢，模塊之間、開發人員之間協作都比較混亂，經常有衝突，而且沒有統一的寫法，不規範，可維護性很差

我認為backbonejs之類的js　mvc庫的作用是把model的狀態由伺服器端轉移到瀏覽器。這點是以後發展的趨勢，因為瀏覽器的運算能力越來越強。這類的js　MVC框架很多而且越來越多。

backbonejs的優勢是她出現的比較早。

具體到backbonejs，他是一個輕量級別的mvc庫，優點是簡單，學習曲線比較平坦，上手快。和jquery的結合很簡單。可以選擇合適自己的UI庫。和jquery　ui結合還是很便利的。對於在客戶端交互稍微複雜一點的ajax程序都可以考慮使用。

但是對ui比較多的場合不太合適，因為jquery　UI　的庫比較起　dojo　的還是很弱的。而dojo之類的庫都有自己的js端的mvc機制。

Backbone的體量頂多算是個庫，還稱不上框架。

後期體量增長到比較大的項目，都會產生自己的Backbone。

Backbone這個庫更適合新手學習，想圖開發方便的話，可以使用MVVM框架。

前端RIA+REST後端

也許類似Backbone的前端+NodeJs的REST後端是將來的發展方向。

類似http://tiptap.com的體驗感覺很棒。

補充一下，

1：輕型單頁富應用可以使用backbone，他的優勢在於官方推薦與jq結合學習成本低，快速簡練。

2：重型使用extjs或者sencha touch，學習成本高，沒讀過源碼很難寫出優雅的增強組件，也很難利用框架的設計思想來完成自己的業務原型。3：

最近kissy更新了1.2裡面的mvc模型和解偶思想都值得各前端去深入。

個人傾向於sencha系，原因是源碼邏輯清晰可讀和可學習性強，擁有世界首屈一指的doc,而且sencha團隊的迭代能力極強。

backbone.js還是有很多可以用的東西的。比如control做的事情是hash值轉換成視圖。model上可以達到跟後台一樣的model get/set 。view層就是一個事件綁定。使用backbone.js開發出來的項目思路會比較清晰，模塊化比較科學。只是backbones.js有點臃腫，依賴一個underscore。原生方法的擴展比較多。實際上這些原生方法的擴展比較容易產生衝突，而且很多都用不太上。

backbone是第一代前端mvc，它能幫你組織代碼解耦，我一開始也用過他組織代碼，然後呢？什麼都沒有了。即便一個很簡單的功能也要有一個基本的構建，大量暴露出來的機制必須你自己手動控制，比如何時監聽什麼東西對象集合的各種事件，何時如何render，學習成本並不低，backbone你也需要jq+靜態模版，不減少任何代碼，然後用了backbone的Model，Collection反而增加了代碼量，然後漸漸的發現還不如不用自己組織代碼好了。。總之學一下也沒壞處，但還是找個mvvm用吧。

玩backbone，需要有一定的js基礎才玩得轉。

因為覺得手機中的單頁面載入體驗不錯，所以想用下backbone.js中的 route ，至於MVC我倒是沒啥興趣！希望能把route 這個功能單獨分離出來！

12年那會兒在公司的項目中引入backbone，在當時的熱度也是很高的，Model，Collection，View，Router，這些都為當頁面開發帶來了極大地便利。但backbone屬於比較早期的MVC框架，與現在的各種框架相比，也相對原始，更純粹，於當期很火的很多MVVM框架相比，開發人員可干預的東西也相對多一些，而且是view層的實現也是相對比較落後的。另外討論backbone的適用場景，倒不如討論mvc的適用場景。無論是任何庫、框架的誕生都是為了解決某些普適問題的，而框架的意義一是方便我們卻解決一些問題，另一方面其實約束開發人員去按照一定的規範去做一些事情。如果你的業務需求在抽象之後，適合mvc開發，那用backbone 並搭配其他的東西，就沒有問題。

目前公司正在使用backbone，像上面說的，backbone肯定是最適用於SPA的，然後個人覺得最重要的一點Backbone將頁面中的數據、邏輯、視圖解耦，依照Backbone進行代碼結構組織，可以將項目中的數據交互、業務邏輯、用戶界面等工作，分配給多個同事同時開發，並能有序地組織到一起。這對於大型和複雜項目的維護開發非常有幫助。

其實我和期待backbone 中的pushstate的使用