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?

  • 1
    I am curious about your approach. Why bother using ASP.NET as a client technology anyway if you are not using any ASP.NET controls?
    – NoChance
    Commented Dec 3, 2012 at 21:59
  • 1
    I often ask myself the same question. The answer is: WebForms is what we know. We do still use MasterPages, but that's about it. What would you suggest? Commented Dec 3, 2012 at 22:18
  • Since you already have an application in production, I don't think that it is wise to change the current architecture specially if the application is not trivial. I would suggest that for future implementations, you either utilize VS20xx controls, third party controls and/or HTML5+JavaScript but stay away from manipulating DOM directly in a business application if you could. Also, this may be of value to your case: kendoui.com/blogs/teamblog/posts/12-06-05/…
    – NoChance
    Commented Dec 4, 2012 at 5:18
  • Thanks for the input, but I think you may be confused about the types of applications we are writing. DOM manipulation is a big part of how refreshless rich web apps work. Going back to Web Controls would be a step backwards. Commented Dec 4, 2012 at 13:17

1 Answer 1


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.

  • Option 1 sound appealing. How would I go about getting started with that? Would that involve using the Web API and inheriting from ApiController, like: asp.net/web-api/overview/hosting-aspnet-web-api/… . Commented Dec 3, 2012 at 22:23
  • I haven't done any API development with .Net, but that looks right. You'd then tell Backbone to sync with the URLs defined in the Routes section of your server side code.
    – Shauna
    Commented Dec 4, 2012 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.