将backbone.js与ASPNET MVC集成是否有意义？

Question

我不是这些构建模块的专家，但乍一看似乎在我看来：

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

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

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

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

如果有人可以推荐我，我希望看到一些分析或讨论。

Answer 1

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

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

为什么ASP.NET MVC很棒

• 布局（MasterPages）
• Razor（具有智能感知良好的类型安全视图）
• ActionFilters（应用日志记录，身份验证等惯例的绝佳地点）
• 免费的JSON序列化 - return Json(model)
• 模型绑定和验证
• IoC和MVC是最好的朋友（获胜）
• 身份验证+授权
• 很多其他我无法想到的东西。

通过使用客户端框架进行视图生成，你真正想念的只是Razor。您甚至可以在某种程度上利用布局。

我使用ASP.NET MVC进行开发的方法是首先使应用程序在服务器端工作。这会强迫您考虑您希望您的URL结构，值得控制器的内容，以及您的路由应该是什么。它还意味着您可以在第一次迭代视图中获得类型安全和自动完成的好处。在本练习结束时，您将获得一个简单的，符合标准的解决方案（希望如此），该解决方案适用于人类已知的任何设备，Google无法获得足够的。

然后我开始采用渐进方法来实现客户端功能的切片。在客户端，我写了一些javascript来劫持我想要变成AJAX请求的请求，并使用Razor视图的翻译版本来处理响应。在服务器端，我使用动作过滤器采用基于约定的方法。此操作过滤器大致执行以下操作：

• ActionResult是ViewResult吗？
  • 什么是Accept类型？
    • HTML - 在给定相同模型的情况下返回带有前缀“_”的同名PartialViewResult
    • JSON - 返回给定相同模型的JsonResult
• ActionResult是否为RedirectToRoute结果？
  • 返回EmptyResult（或者您可以选择在JsonResult中返回URL）

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

从服务器端实现开始的浪费是你在视图生成代码（基于Razor + js的模板）中加倍。根据您希望在客户端实施的应用程序的数量，这可能是也可能不是问题。 Spark是个例外，因为你实际上可以把它送到generate client templates给你！ Spark的缺点是你失去了intellisense（它有一个插件，但它的垃圾）这不是一个微不足道的损失，而且我只是更喜欢Razor（它的烘焙，不需要配置，并且不会随时消失不久）。

Answer 2

我已经将asp.net mvc KO和bakcbone用于不同的项目，最终归结为项目的本质。一旦工作流程开始变得复杂，或者您要提供的用户体验不像简单的以数据数据为中心的应用程序，服务器堆栈就不会开箱即用。当你的项目涉及伟大的UX骨干时，你可以到达那里。下行是没有明确的集中指导方针，你必须通过博客来完成任务。对于传统的应用程序，你可以坚持KO。顺便说一句，有些插件可以模拟KO for backbonejs ..我再次提到bacjbone.modelbinder你需要整合你的自己Cuz MS根本不会打扰。