将backbone.js 与ASPNET MVC 集成是否有意义? [英] Does it make sense to integrate backbone.js with ASPNET MVC?

问题描述

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

I'm not an expert in these building blocks, but at first glance it seems to me:

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

• ASPNET MVC wants to generate the views and manage the models for an app on the server side. It views the browser as a somewhat dumb presentation engine, a consumer of the views that are provided for it by the server.

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

backbone.js would like to generate the views and manage the models in the browser. It views the server-side as a fairly dumb REST-based persistence engine.

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

This seems like a simplistic view. I'm sure it's not the whole story.

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

What are the real opportunities for integrating these two things? Does it make sense to do it? Or is there too much overlap between them for it to make sense?

我喜欢看这方面的一些分析或讨论，如果有人可以推荐给我.

I like to see some analysis or discussion of this, if anyone can refer me.

推荐答案

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

Whilst I cannot speak to backbone.js, I can tell you that I've used knockout to great effect combined with ASP.NET MVC. Every ASP.NET application that I've seen to date uses a mix of client-side and server-side view generation. There is always going to be times where its more convenient to generate views server-side. Take for example conditional UI elements based on whether or not a user is authenticated, or whether they have a specific permission. You may not want a web savvy user to be able to explore your client side templates and work out all the features they're not getting. Sure you could get around this by asynchronously loading different client templates, blah blah, or wind up writing server-side code to generate your client-side templates... Furthermore if SEO means anything to you, you can kiss client-side templating (by itself) goodbye.

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

So the sweet spot, in my opinion, is something that does both well. In my experience I have found ASP.NET MVC to excel at both.

为什么 ASP.NET MVC 很棒

• 布局(母版)
• Razor(具有智能感知优势的类型安全视图)
• ActionFilters(应用日志、身份验证等约定的绝佳场所)
• JSON 序列化免费 - 返回 Json(model)
• 模型绑定和验证
• IoC 和 MVC 是最好的朋友(胜利)
• 身份验证 + 授权
• 还有很多我想不到的东西.

通过使用客户端框架生成视图，您真正错过的只是 Razor.您甚至可以在一定程度上利用布局.

By using a client-side framework for view generation really all you're missing out on is Razor. You can even leverage layouts to some degree.

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

The approach that I take to development with ASP.NET MVC is to start by making the application work server-side. This forces you to think about you want your URL structure, what deserves a controller, what your routes should be. It also means you get the benefit of type-safety and auto-complete during the first iteration of views. At the end of this exercise you've got a simple, standards compliant solution (hopefully) that works on any device known to man, that Google can't get enough of.

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

I then set about taking an incremental approach to implementing slices of client-side functionality. On the client side I write some javascript to hijack a request that I want to turn into an AJAX request, and handle the response using a translated version of the Razor view. On the server side I take a convention-based approach using an action filter. This action filter does approximately the following:

• ActionResult 是 ViewResult 吗?
  • 什么是接受类型?
    • HTML - 在给定相同模型的情况下，返回以_"为前缀的同名 PartialViewResult
    • JSON - 返回给定相同模型的 JsonResult
    • 返回 EmptyResult(或者您可以选择在 JsonResult 中返回 URL)

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

    With this approach you can add AJAX functionality without changing a single line of code in controllers. An alternative approach is to follow the Thunderdome Principal and have an ActionInvoker responsible for wrapping the model in an appropriate result type based on the request context. I haven't worked out how server side navigation (redirects) fit with this approach though.

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

    The waste in starting with a server-side implementation is you're doubling up in view generation code (Razor + js-based template). Depending on how much of your application you want to implement at the client, this may or may not be a problem. Spark is the exception to this in that you can actually get it to generate client templates for you! The downside to Spark is that you lose intellisense (there's a plugin for it but its crap) which is not an insignificant loss, plus I just prefer Razor (its baked in, doesnt need to be configured, and isn't going away any time soon).

    这篇关于将backbone.js 与ASPNET MVC 集成是否有意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！