这是否有意义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要产生的意见和管理模型在服务器端的应用程序。它认为浏览器作为一个有点哑presentation发动机，由服务器提供它的看法消费者。

• 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的说话，我可以告诉你，我已经用淘汰赛有很大的影响的ASP.NET MVC结合起来。我已经看到了迄今为​​止所有的ASP.NET应用程序使用客户端和服务器端视图生成的混合。总有将是倍，其中其更方便地生成意见服务器端。就拿根据是否不是用户的例子有条件的UI元素进行身份验证，或者他们是否有特定的权限。您可能不希望网络精明的用户能够探索你的客户端模板，并制定出所有不予理会的功能。当然，你可以解决这个问题通过异步加载不同的客户端模板，等等等等，或清盘编写服务器端code生成您的客户端模板......此外，如果搜索引擎优化意味着什么给你，你可以亲吻客户端 - 端模板（本身）再见了。

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是真棒

• 布局（MasterPages）


• 剃须刀（带智能感知善良类型安全视图）


• ActionFilters（申请约定如日志，权威性真棒斑等）


• JS​​ON序列化的自由 - 返回JSON（模型）


• 模型绑定和验证


• 国际奥委会和MVC是最好的朋友（WIN）


• 验证+授权


• 的，我不能想到的。其他的东西很多

通过使用视图生成一个客户端框架真的你错过了所有的剃刀。你甚至可以利用布局，在一定程度上。

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结构，有什么值得控制器，你的路线应该是什么。这也意味着你得到的意见第一次迭代时类型安全和自动完成的好处。在这项工作结束时，您已经有了一个简单的，符合标准的解决方案，（希望）是人类已知的任何设备上工作，，谷歌无法获得足够的。

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 - 返回_鉴于同型号
    pfixed相同的名称$ P $的PartialViewResult
    
    • JS​​ON - 返回一个JsonResult给予同样的模型
    
    
    • Is the ActionResult a ViewResult?
      • What is the Accept type?
        • HTML - Return a PartialViewResult of the same name prefixed with "_" given the same model
        • JSON - Return a JsonResult given the same model
        
        
        • 返回EmptyResult（或任意可以返回一个JsonResult的URL）
        
        

        通过这种方法，你可以在不改变code一行在控制器添加AJAX功能。另一种方法是遵循 Thunderdome主要并有一个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.

        在服务器端执行的开始是浪费你的视图生成code增加了一倍（基于JS-​​剃刀+模板）。取决于你想要多少应用程序在客户端执行，这可能会或可能不会成为一个问题。星火是例外的，你实际上可以得到它的<一个href=\"http://odeto$c$c.com/blogs/scott/archive/2009/03/12/client-rendering-views-with-spark-and-asp-net-mvc.aspx\">generate客户端模板为您服务！星火缺点是，你失去了智能感知（有它，但它的废话一个插件），这是不是一个微不足道的损失，再加上我只是preFER剃刀（其烤，那并不需要进行配置，并且不会很快离开任何时候）。

        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屋！