asp.net-mvc - 将backbone.js 与ASPNET MVC 集成是否有意义？

Question

我不是这些构建块的专家，但乍一看似乎是这样:

ASPNET MVC 希望在服务器端生成 View 并管理应用程序的模型。它将浏览器视为一个有点愚蠢的呈现引擎，是服务器为其提供的 View 的使用者。

Backbone.js 想在浏览器中生成 View 并管理模型。它将服务器端视为一个相当愚蠢的基于 REST 的持久性引擎。

这似乎是一个简单的观点。我确定这不是故事的全部。

整合这两件事的真正机会是什么？这样做有意义吗？
或者它们之间是否有太多重叠而没有意义？

我喜欢看一些对此的分析或讨论，如果有人可以推荐给我。

Answer 1

虽然我不能和backbone.js 说话，但我可以告诉你，我已经将淘汰赛与ASP.NET MVC 结合使用，效果非常好。迄今为止，我见过的每个 ASP.NET 应用程序都混合使用客户端和服务器端 View 生成。总有一些时候在服务器端生成 View 更方便。以基于用户是否经过身份验证或是否具有特定权限的条件 UI 元素为例。您可能不希望精通网络的用户能够探索您的客户端模板并计算出他们没有获得的所有功能。当然你可以通过异步加载不同的客户端模板来解决这个问题，等等，或者最终编写服务器端代码来生成你的客户端模板......此外，如果 SEO 对你来说意味着什么，你可以亲吻客户端模板(本身)再见。

因此，在我看来，最佳点是两者兼而有之。根据我的经验，我发现 ASP.NET MVC 在这两个方面都很出色。

为什么 ASP.NET MVC 很棒

布局(母版)

Razor(具有智能感知优势的类型安全 View )

ActionFilters(适用于日志记录、身份验证等约定的好地方)

免费的 JSON 序列化 - return Json(model)

模型绑定(bind)和验证

IoC 和 MVC 是最好的 friend (胜利)

认证+授权

还有很多我想不出来的东西。

通过使用客户端框架生成 View ，您真正错过的只是 Razor。您甚至可以在某种程度上利用布局。

我使用 ASP.NET MVC 进行开发的方法是首先使应用程序在服务器端工作。这迫使你考虑你想要你的 URL 结构，什么值得一个 Controller ，你的路由应该是什么。这也意味着您可以在第一次 View 迭代期间获得类型安全和自动完成的好处。在本练习结束时，您将获得一个简单的、符合标准的解决方案(希望如此)，该解决方案适用于人类已知的任何设备，而 Google 对此无法满足。

然后，我开始采用增量方法来实现客户端功能的各个部分。在客户端，我编写了一些 javascript 来劫持我想转换为 AJAX 请求的请求，并使用 Razor View 的翻译版本处理响应。在服务器端，我使用 Action 过滤器采用基于约定的方法。此操作过滤器大致执行以下操作:

ActionResult 是 ViewResult 吗？

什么是接受类型？

HTML - 在给定相同模型的情况下，返回以“_”为前缀的同名 PartialViewResult

JSON - 在给定相同模型的情况下返回 JsonResult

ActionResult 是 RedirectToRoute 结果吗？

返回 EmptyResult(或者您可以选择在 JsonResult 中返回 URL)

使用这种方法，您可以添加 AJAX 功能，而无需更改 Controller 中的任何一行代码。另一种方法是遵循 Thunderdome Principal并有一个 ActionInvoker 负责根据请求上下文将模型包装在适当的结果类型中。不过，我还没有弄清楚服务器端导航(重定向)如何适应这种方法。

从服务器端实现开始的浪费是您在 View 生成代码(Razor + 基于 js 的模板)中加倍。根据您希望在客户端实现多少应用程序，这可能是也可能不是问题。 Spark 是一个异常(exception)，因为您实际上可以将其发送至 generate client templates为你! Spark 的缺点是你失去了智能感知(它有一个插件，但它的废话)这不是一个微不足道的损失，而且我更喜欢 Razor(它已经内置，不需要配置，并且不会消失任何时间很快)。