我不是在這些積木的專家，但在乍看之下，似乎對我說：將backbone.js與ASPNET MVC集成是否有意義？
ASPNET MVC要產生的意見和管理模型，在服務器端的應用程序。它將瀏覽器視爲一種有點愚蠢的展示引擎，它是服務器爲其提供的視圖的消費者。
backbone.js想要在瀏覽器中生成視圖並管理模型。它將服務器端視爲一個相當愚蠢的基於REST的持久性引擎。
這看起來很簡單。我相信這不是整個故事。
整合這兩件事情的真正機會是什麼？這樣做有意義嗎？ 或者它們之間有太多重疊，因爲它有意義？
我喜歡看到這個分析或討論，如果任何人都可以引用我。
雖然我不能說到backbone.js，但我可以告訴你，我已經使用knockout與ASP.NET MVC結合起來。我見過的每個ASP.NET應用程序都使用客戶端和服務器端視圖生成的混合。總會有一些時候更方便的在服務器端生成視圖。例如，根據用戶是否通過身份驗證或者他們是否具有特定權限來獲取條件UI元素。您可能不希望精通網絡的用戶能夠探索您的客戶端模板並計算出他們未獲得的所有功能。當然你可以通過異步加載不同的客戶端模板來解決這個問題，等等，或者結束編寫服務器端代碼來生成你的客戶端模板...此外，如果SEO意味着什麼給你，你可以吻客戶端模板（本身）告別。
所以，在我看來，甜蜜的地方，兩者都有。根據我的經驗，我發現ASP.NET MVC在兩方面都很出色。
爲什麼ASP.NET MVC是真棒
return Json(model)通過使用客戶端框架進行視圖生成真的所有你錯過了Razor。你甚至可以在一定程度上利用佈局。
我使用ASP.NET MVC進行開發的方法是先讓應用程序在服務器端工作。這迫使你想想你想要你的URL結構，什麼值得控制器，你的路線應該是什麼。這也意味着您可以在視圖的第一次迭代期間獲得類型安全性和自動完成的好處。在本練習結束時，您會得到一個簡單的，符合標準的解決方案（希望是）可以在任何人都知道的設備上工作，Google無法獲得足夠的解決方案。
然後我開始着手採用增量方法來實現客戶端功能片。在客戶端，我寫了一些JavaScript來劫持一個請求，我想將它變成一個AJAX請求，並使用Razor視圖的翻譯版本處理響應。在服務器端，我使用一個基於約定的方法使用動作過濾器。此動作過濾器大致如下：
通過這種方法，你可以在不改變的一行代碼在控制器添加AJAX功能。另一種方法是遵循Thunderdome Principal並且有一個ActionInvoker負責根據請求上下文將模型包裝成合適的結果類型。儘管如此，我還沒有弄清楚服務器端導航（重定向）如何適合這種方法。
與服務器端執行開始將廢物是你在視圖生成代碼（基於JS-剃刀+模板）增加了一倍。根據您希望在客戶端實現多少應用程序，這可能會也可能不會成爲問題。 Spark是這個例外，因爲你可以爲你實際獲得generate client templates！星火缺點是，你失去了智能感知（有它，但它的廢話一個插件），這是不是一個微不足道的損失，再加上我只是喜歡剃刀（其烤，那並不需要進行配置，並且是不會消失的任何時間不久）。
雖然這是一個引人注目的答案，但我仍然希望看到一個專門與Backbone相關的答案，並提供一些指向實例的鏈接。 –
我對不同的項目使用了asp.net mvc KO和bakcbone，最終都歸結爲項目的性質。一旦您的工作流程開始變得複雜，或者您將提供UX，與簡單的以數據爲中心的應用程序不同，服務器堆棧將不會出現。當你的項目涉及到偉大的用戶體驗骨幹時，你可以在那裏找到你..缺點是沒有明確的集中指導方針，你必須通過博客才能完成任務。對於傳統的應用程序，你可以堅持使用KO。順便說一句，有插件，可以嘲笑KO的backbonejs ..我指bacjbone.modelbinder再次你需要爲你自己集成Cuz MS不會打擾一切。
+1，期待回覆。你還考慮[knockout.js（http://knockoutjs.com/）和[spine.js（http://spinejs.com/）？脊柱似乎不如骨幹更出名，但我已經讀了很多關於它的好消息。 –
雖然不一定直接關係到你的問題，有關於骨幹和淘汰賽這裏商量好了：http://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js-vs 關於這一點，我也期待着對此的迴應。 – Jesse