Previously I’ve spoken about how the ASP.NET Ajax can be used and abused. It offers a very quick and simple framework to make parts of your webpage asynchronous, mainly through use of the UpdatePanel. The tradeoff is the responsiveness of your site, and the fact that the Viewstate needs to be passed with every call. A way around the ASP.NET Ajax bloat is to use Json, which provides simple and lightweight communication with the server, at the cost of a little more complexity and loss of maintainability.

A common scenario in using ASP.NET Ajax is to put a GridView or other data based control into an update panel, with a Timer to continually poll the data. This would look something like:

This is a grid that would get updated every 5 seconds.

Unfortunately, if you had 3 of these suckers on the page, or if the data source gets updated sporadically, you’re going to see a big viewstate being handed back and forth every 5 seconds. Consider this chunk of HTML:

The viewstate is not small. As such, you want to reduce the number of ASP.NET Ajax calls as best you can. So what can you do? Firstly, get rid of all those Timers. If you’re checking for a batch of updates, you only really want to use one call. You can do this using a single call to a web service that returns the update “triggers” so to speak, that are held within the update panels:

To call the webservice on a timed basis, all you need to do is take advantage of javascript’s SetInterval(delegate, n) function, which executes a given function every n milliseconds. With the new TextBox triggers, your modified HTML will look like:

One thing to note specific to this example is that it would probably want to throw a js error on RefreshPanel(), as the triggerName parameter passed to it is the ID of the control, rather than the ClientID. 

The whole point of this design is to use the heavy duty ASP.NET Ajax calls only to update the data. In the interim, we use lightweight Json calls to see if anything has actually been updated. For data that gets updated “every now and then”, this model helps eliminate more bandwidth intensive calls through ASP.NET Ajax, which ultimately could all be for no purpose if the underlying data is still the same.

From the past few posts, I’ve demonstrated how we can implement Json and Web.Services as an alternative to ASP.NET Ajax, and lastly how they can work side-by-side. As I’ve mentioned in the past, sometimes one method is superior to the other, but that’s the fun of IT – it’s your call as to which one you feel is best to use.

In JSON, passing objects from javascript to .net web services is a cinch. In fact, it’s easier by far than doing it in the old Xml notation.

In my last post I spoke about how you can reduce the bloat of your apps by not being so reliant on the ASP.NET AJAX implementation, and going with lightweight JSON calls. In the example, I was passing string values around as parameters and return values which worked quite well.

However oftentimes you’ll want to be moving around your own objects and other complex types, and converting these objects back to their primitive types on each method is something that would drive you nuts.

Fortunately both the javascript and .net frameworks provide a way of doing these things for us, without us having to write even a single line of code.

First, let’s create a web service that returns us a fictional instance of a Person class called ‘Gary’:

Essentially we create Gary, and a few of his family members. The purpose here is to create a complex type – you wouldn’t actually want to create people in this way!

We create the service as a script service so it’s accessible via the javascript in our page. Calling the web service method then becomes a breeze:

I’m using Firefox with the Firebug plugin installed. I’ve found this to be one of the best javascript debuggers out there, and it’s not as fiddly to use as the one built into visual studio. I simply set a breakpoint on the var setBreakpoint; line, click the link in the browser, and my result value looks like this:

How easy is that? This means that to get attributes associated with “Gary” in the javascript, I just need to write code like:

result.Firstname //”Gary”;

result.Age // 42

result.Relatives.daughter.Firstname // “Sabrina”

and so on!

Oh, and the other thing is too, don’t worry about the bloat on the wire. Because this doesn’t use server controls, the only data being set back and forth is going to be related soley to your objects. To illustrate the point, “Gary” the Person object comes back as:

Response

{“__type”:”MyAjax.Person”,”Firstname”:”Gary”,”Lastname”:”Familyman”,”Age”:42,”Relatives”:{“wife”:{“__type”:”MyAjax.Person”,”Firstname”:”Betty”,”Lastname”:”Familyman”,”Age”:40,”Relatives”:{}},”daughter”:{“__type”:”MyAjax.Person”,”Firstname”:”Sabrina”,”Lastname”:”Familyman”,”Age”:10,”Relatives”:{}},”son”:{“__type”:”MyAjax.Person”,”Firstname”:”Mike”,”Lastname”:”Familyman”,”Age”:12,”Relatives”:{}}}}

Which really is as terse and succinct as you can get.

Passing objects around in JSON / ASP.NET AJAX is just as easy as passing primitive types. The advantage is that you don’t need to send the viewstate or any other information, hence can achieve far superior speed and efficiency gains in your web application.

In my last post, I touched on the bloat that ASP.NET AJAX adds to your site, and ways of reducing the viewstate overhead for asynchronous calls.

This time round, I want to speak more about JSON and Web Services.

JSON (JavaScript Object Notation) is an extremely lightweight data structure that Web Services built in .NET can understand and interpret. Web Services are typically associated with XML calls, which although are verbose and readable, aren’t much fun to create in Javascript and often end up hogging all your bandwidth.

JSON gets compressed into a single string, which gets passed to your web service that then constructs that string back into an object. For those living with in .NET 3.0 land out there, JSON is very similar to Object Initialisers.

So now we have a lightweight object notation that can communicate with Web Services built in .NET. Great. But how can we leverage these technologies to reduce the bloat of ASP.NET AJAX?

This all comes down to your architecture and how your pages get used. If you put a DataGrid within an UpdatePanel to achieve asynchronous everything, it’s going to be difficult to replace that functionality with JSON and Web Service calls.

However, if you have a couple of text boxes and a submit button within an UpdatePanel that sends the text box values off to the server, chances are you can replace this with a JSON implementation. Consider this basic scenario:

Which would give something like the following:

That’s an easy implementation, but how does it look on the wire?

Request:

ctl02=upGreetMe|lnkSubmit&__EVENTTARGET=lnkSubmit&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUKMjA3OTY1ODc0N2RkcEMKQ
DsHztIsqEaftQkNhQqa9L8%3D&txtFirstname=Andrew&txtLastname=den%20Hertog&__EVENTVALIDATION=%2FwEWBAKev73aCwLZh62
pDwKdlcWkAgKg%2BLK0C8JDoC%2F8jw%2BvvB1lvzQCJ%2B0MXZCK&

Response:

cc

177|updatePanel|upGreetMe|

                <div id=”pnlOutput”>

                    <span id=”lblGreeting”>Welcome: Andrew den Hertog</span>

</div>

            |

1d8

228|hiddenField|__VIEWSTATE|/wEPDwUKMjA3OTY1ODc0Nw9kFgICAw9kFgICAw9kFgJmD2QWBAIBDw8WAh4HVmlzaWJsZWhkFgQCAQ8PFg
IeBFRleHQFBkFuZHJld2RkAgMPDxYCHwEFCmRlbiBIZXJ0b2dkZAIDDw8WAh8AZ2QWAgIBDw8WAh8BBRpXZWxjb21lOiBBbmRyZXcgZGVuIEhl
cnRvZ2RkZD1YbZtEvITGhXSRS3Xr2lM4dxyZ|0|asyncPostBackControlIDs|||0|postBackControlIDs|||10|updatePanelIDs||tup
GreetMe|0|childUpdatePanelIDs|||9|panelsToRefreshIDs||upGreetMe|2|asyncPostBackTimeout||90|9|formAction||test.
aspx|12|pageTitle||Ajax Example|

0

So for the most basic of calls, with NO other controls on the screen at all, you’re still looking at a round trip payload of 274 upstream + 668 downstream = 942 bytes. Might not seem like much yet, but once you put more controls on your screen, that sucker’s going to get big.

Achieving this in JSON is a bit more involved, but not impossible.

First thing you need to do is to create a webservice, call it WebService.asmx. It should look something like this:

Next thing is we need to overhaul the original web page so that it only uses web service method calls:

To explain the code, we’ve blown away the update panels, converted the regular panels to divs, and got rid of all server controls.

The script manager on the page has a ServiceReference to WebService.asmx, which creates the javascript function MyAjax.WebService.Greet() which makes calls to the Web Service very simple. For this to work, you need to ensure that your web service contains the attribute [ScriptService]

The hiding and showing of divs is simple javascript/css manipulation.

You’ll notice when I call the Web Service method Greet(string, string) I’m passing three parameters. The third parameter is a delegate which gets executed on a successful round trip, with the return value held in returnVal.

This seems like a lot of work, but lets see what the benefits are in terms of our network usage:

Request:

{“firstname”:”Andrew”,”lastname”:”den Hertog”}

Response:

“Welcome: Andrew den Hertog”

That’s a roundtrip of upstream 46 + downstream 26 = 72bytes in total. That’s just 7% of the overhead from the original model. Furthermore if you added more server controls to the page, this method will always just return 72bytes, whereas the ASP.NET AJAX implementation will grow and bloat to accomodate the viewstate.

To reiterate, ASP.NET AJAX is very easy to work with, but it does add significant overhead to your system. Using JSON and Web Services where possible will speed up your site, but perhaps at the loss of code maintainability and site complexity. It’s your call to see where you should and shouldn’t change your approach, but the more you can do to reduce your network usage, the fast your site will appear and the happier the end user will be.

I’ve worked with ASP.NET AJAX long enough now to appreciate both the increases in productivity on the development side, whilst also discovering the significant bloat it adds to sites where it’s implemented. In light of this, I’ve decided to put up a number of posts on how you can reduce the dependancy your sites have on this model.

On the development side of things, the ASP.NET AJAX model is fantastic. Any part of your site that you want working asynchronously you just drop inside an UpdatePanel and you’re away. You don’t need to code nor maintain any javascript, it’s simply plug & play.

However with this convenience comes a lot of overhead. Not only do visitors to your site have a significant initial download to get all the javascript libraries, each call from a control or trigger for an UpdatePanel will then cause the entire viewstate for that page to be sent to the server, and a new one returned. This is where things can get out of hand.

For small sites with a limited number of sever controls on a page, the viewstate can be quite small and hence this isn’t an issue. However as the size and scale of your site increases, it’s almost inevitable that more server controls will be added to your page, increasing the viewstate size, and each subsequent postback to the server.

To check out exactly what and how much is being sent back and forth between your browser and your web server, I highly recommend an HTTP logger such as the likes of Fiddler 2 by Eric Lawrence. This will let you see the raw output of everything that gets sent between your browser & server.

Now, lets take your site into account that uses the ASP.NET AJAX model, what’s the first thing you can do to improve the efficiency of your site?

The obvious answer to this is to reduce the number of server controls you have on your site. A common mistake is to use labels as containers for static text. When you add a label to your site, it inevitably gets turned into a <span></span> block, with the additional overhead of increasing the viewstate size. For this reason, you should aim to convert as many of your labels into <span></span> blocks as you can.

But what if the text for the label is set dynamically? You can still use server-side scripting within your HTML. Take for instance a simple “Welcome <Name>” label. In your page source it looks something like:

and your code behind:

On the client side, it will turn up as:

with our viewstate going from:

/wEPDwUJNzgzNDMwNTMzZGRAXRyhyf+YSOvbHZfmj+wHXiuDGg==

to

/wEPDwUJODExMDE5NzY5D2QWAgIDD2QWAgIBDw8WAh4EVGV4dAUaV2VsY29tZTogQW5kcmV3IGRlbiBIZXJ0b2dkZGS52vt7OHtVWwBQyWufRS3o2gv/LQ==

It’s not so bad right? I mean this has only increased the viewstate by a little bit. But what happens if we had lots of labels? Or even just had heaps of text pouring into one?

Our viewstate turns into a monster:

/wEPDwUJODExMDE5NzY5D2QWAgIDD2QWAgIBDw8WAh4EVGV4dAXoB2FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFkZGQrwjhWv3Cqncvs3Zebq60sXhc/Ug==

The far better option in either case is to plant the text directly into your HTML to prevent it being added to your viewstate:

Viewstate:

/wEPDwUJOTU4MjMyMzI1ZGTGMsJAGEAyzW+ZLZ++DQd01dNucA==

That’s far more economical.

It’s almost impossible to eliminate all of the server controls for your page, however reducing them can significantly subtract from the viewstate overhead you incur. Now remembering that for every ASP.NET AJAX call you make you send back the viewstate. This viewstate includes the state of ALL the controls on the page, not just the ones inside your UpdatePanel. By reducing the number of server controls on your page, you can potentially stand to gain some significant bandwidth reductions and subsequent performance increases on your site.