我不是这些构建模块方面的专家，但乍一看在我看来：
ASPNET MVC 想要为服务器端的应用程序生成视图并管理模型。它将浏览器视为一个有点笨拙的呈现引擎，是服务器为其提供的视图的消费者。
backbone.js 想在浏览器中生成视图和管理模型。它将服务器端视为一个相当愚蠢的基于 REST 的持久性引擎。
这似乎是一个简单的观点。我敢肯定这不是故事的全部。
整合这两件事的真正机会是什么？这样做有意义吗？ 还是它们之间有太多重叠而没有意义？
如果有人可以推荐我，我希望看到对此的一些分析或讨论。
【问题讨论】：
虽然我不能与backbone.js 交谈，但我可以告诉你，我已经将淘汰赛与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 负责根据请求上下文将模型包装在适当的结果类型中。不过，我还没有弄清楚服务器端导航（重定向）如何适应这种方法。
从服务器端实现开始的浪费是您将视图生成代码（Razor + 基于 js 的模板）加倍。根据您希望在客户端实现多少应用程序，这可能是也可能不是问题。 Spark 是个例外，因为您实际上可以为您将其发送至generate client templates！ Spark 的缺点是你失去了智能感知（它有一个插件，但它是废话），这不是一个微不足道的损失，而且我更喜欢 Razor（它已内置，不需要配置，并且不会消失）很快）。
【讨论】：
我在不同的项目中使用过 asp.net mvc KO 和 bakcbone，最终这一切都归结为项目的性质。一旦您的工作流程开始变得复杂，或者您要提供与简单的以数据为中心的应用程序不同的 UX，服务器堆栈就不会开箱即用。当您的项目涉及出色的 UX 时，backbonejs 可以让您到达那里。缺点是没有明确定义的集中指导方针，您将不得不通过大量的博客才能完成工作.. 对于传统应用程序，您可以坚持使用 KO。顺便说一句，有一些插件可以模拟 KO forbonejs .. 我指的是 bacjbone.modelbinder 再次你需要为你自己集成因为 MS 根本不会打扰。
【讨论】：