将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)
• 剃刀(具有智能感知的类型安全视图)
• 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是个例外,因为你可以实际为它生成客户端模板!Spark的缺点是你失去了intellisense(它有一个插件,但它的垃圾)这不是一个微不足道的损失,而且我只是更喜欢Razor(它的烘焙,不需要配置,并且不会随时消失不久).