Should Backbone.js Be Implemented in ASP.NET WebForms Applications?

asp.netcode-organizationdesign-patternsjavascriptwebforms

Background

I'm trying to improve my group's current web app development pattern. Our current pattern is something we came up with while trying to rich web apps on top of ASP.NET WebForms (none of us knew ASP.NET MVC). This is the current pattern:

diagram of our pattern!

  • Our application is using the WinForms Framework.

    • Our ASPX pages are essentially just HTML, we use almost no WebControls.

  • We use JavaScript/jQuery to perform all of our UI events and AJAX calls.

    • For a single ASPX page, we have a single .js file.

    • All of our AJAX calls are POSTs (not RESTful at all)

  • Our AJAX calls contact WebMethods which we have defined in a series of ASMX files.

    • One ASMX file per business object.

Why Change?

I want to revise our pattern a bit for a couple of reasons:

  1. We're starting to find that our JavaScript files are getting a bit unwieldy.
  2. We're using a hodgepodge of methods for keeping our local data and DOM updates in sync. We seem to spend too much time writing code to keep things in sync, and it can get tricky to debug.

I've been reading Developing Backbone.js Applications and I like a lot of what Backbone has to offer in terms of code organization and separation of concerns. However, I've gotten to the chapter on RESTful app, I started to feel some hesitation about using Backbone.

The Problem

The problem is our WebMethods do not really fit into the RESTful pattern, which seems to be the way Backbone wants to consume them.

For now, I'd only like to address our issue of disorganized client side code. I'd like to avoid major rewrites to our WebMethods.

My Questions

Is it possible to use Backbone (or a similar library) to clean up our client code, while not majorly impacting our data access WebMethods? Or would trying to use Backbone in this manner be a bastardization of it's intended use?

Anyone have any suggestions for improving our pattern in the area of code organization and spending less time writing DOM and data sync code?

Best Answer

It will depend largely on how you've architected and written your code, but it is possible to retrofit your application to allow for using Backbone.js (and no, I don't think it's necessarily a bastardization).

What you'll need to do is translate your calls somewhere to something that your web services can understand. There are potentially two ways to do this:

  1. Create a server-side API wrapper that sends and receives REST calls. Basically, you'd create an "API"/"router" class that the Backbone application interfaces with. This API translates the REST calls into something that your web services understand. It then translates the information from the webservices back into a RESTful response that the Backbone application understands. (This works really easily if your WebMethods can be called directly from other functions on the servers (IE - "var foo = bar.GetData()" or whatever).)

  2. Override Backbone's sync methods with your own. It is also possible to override the built-in Sync function with your own. Doing this will allow you to build a Sync function set that can understand the type of data you're sending and receiving. This would translate the REST commands (get, set, update, delete) from the applications into commands that comply with your web services.

I personally recommend putting a wrapper around your server side code if possible, so that you can update it in the future, without having to rework your client side code again. However, if you have to go the route of option 2, try to write the rest of your Backbone application as though your web services were a RESTful API, that way you can easily replace your Sync functions with the vanilla Backbone.Sync once you've converted your server.

Related Topic