Does it make sense to integrate backbone.js with ASPNET MVC?

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.

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.

Why ASP.NET MVC is awesome

Layouts (MasterPages)

Razor (type-safe views with intellisense goodness)

ActionFilters (awesome spot for applying conventions like logging, auth, etc)

JSON serialisation for free - return Json(model)

Model-binding and validation

IoC and MVC are best friends (win)

Authentication + authorization

Lots of other stuff that I can't think of.

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.

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.

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:

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

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

HTML - Return a PartialViewResult of the same name prefixed with "_" given the same model

JSON - Return a JsonResult given the same model

Is the ActionResult a RedirectToRoute result? Return EmptyResult (or optionally you could return the URL in a JsonResult)

Return EmptyResult (or optionally you could return the URL in a JsonResult)

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.

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).

---

I have used asp.net mvc KO and bakcbone for different projects and it all comes down to nature of project in the end. Server stack won't go out of the box once your workflows start getting complex or you are to offer UX unlike simple data data centric applications. When your project involves great UX backbonejs can get you there.. Downside is that there are no well defined centralized guidelines for that you will have to go through hell of blogs to get things done .. For conventional apps you can stick to KO. Btw there are plugins that can mock KO for backbonejs .. I'm referring to bacjbone.modelbinder again you need to integrate for your self Cuz MS won't bother at all.

---