Should I implement BackBone.js into my ASP.NET WebForms applications?
- by Walter Stabosz
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:
!
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:
We're starting to find that our JavaScript files are getting a bit unwieldy.
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?
