Update Panel is a quick and (very) dirty way to enable some AJAX on an asp.net webpage. Simply put one or several Update Panels onto a page, with one scriptmanager for the page, usually you'll want to set UpdateMode of the Update Panel(s) to "Conditional", and in case you have user-controls on your page, you might need to set EnablePartialRendering="true" (this is by default set to true I believe) and it often seems to work just great, you get those famous flicker free partial page postbacks that are soo characteristic of AJAX. Unfortunately under the hood the updatepanel causes a full reinstantiationation of the Page’s control tree and every single control runs through its life cycle events.
Problems
I can understand that this abstraction offers certain amount of familiarity and simplicity that maybe some naive programmers will welcome very much, however it is misleading and utterly non-"ajaxy". Just imagine that you generate request and other parameter specific HTML for the same resource on the fly (this is altogether not at all uncommon with many dynamic web 2.0 applications), and you need some AJAX functionality on that HTML-page then the update panel will be an utter nightmare. Since the so called AJAX update-panel actually re-instantiates the entire control tree and runs plugs into the page-life cycle behind the scenes so that all the control events can be accessed nicely from code-behind, your dynamically generated page would need to be re-loaded from the viewstate or session state manually (kinda sucks)!!! See this post, but especially this post to illustrate the extra overhead on your side to achieve this.
Try... get this :-)
Obviously this seems too much work on server side, when all you wanted to do is send/retrieve a little bit of data to your web/db-server asynchronously. The whole idea of AJAX is that you update a small area of the page that needs updating since most of the HTML can stay the way it is a lot of bits on the wire & server processing time can be potentially saved. The side effect of which is a flicker free, quick, responsive web-page. With the asp.net update-panel it seems the main goal of the control is a flicker free update. I found a post that highlights the common mistakes with the update panel where some comments sadly point out the misleading opinion that this is a down to earth logical design. The truth is that once you know what the update-panel does exactly you can live with it, in some basic situations it might be quite alright to use it, but it certainly isn't good AJAX by design by any standard.
The illustration below illustrates the desired AJAX scenario:
So problems begin if for example you generate controls dynamically based on the first page load, or by user-interaction, this is very common in todays dynamic web. If an update panel is used in such a common scenario then it is necessary to keep track of the controls that have been generated - usually this has to be done in the viewstate, and the framework doesnt do it for you, you do have to code up the viewstate state preservation (i.e. saving / retrieving from viewstate at the right time of the page lifecycle) yourself. This can bring a great deal of unexpected and most importantly unneeded complexity.
Of-course you can decide to stick with the update panel [for some very, highly, extremely strange reason :-)], and you can take care of the state management of dynamically generated controls as it is described in this stackoverflow.com post, or this one. Have fun ;-)...
The Solution (page methods, etc...):
Fortunatelly we can simply use direct AJAX calls. As Microsoft engineers realised that update panel (in most non-trivial scenarious) simply sucks and provided us with alternatives, specifically page methods, these are great, essentially a webservice type of method that can be declared as a static public method in my webpage class, raher than having to create a new web-service to expose the method. Page-methods allow to keep code in one place and I love them. Data is by default returned in JSON, but the format can easily be changed to XML for example (since JSON, isn't capable of representing certain complicated self-referential data-item). Check out this page for a good example of pagemethod in use.... Of course standard webservices can also be used, the options are discussed in some detail withing this great MSDN Magazine article written by Jeff Prosise on some options, other than the UpdatePanel.
JQuery or for that matter any other ajax supporting javascript library can be used instead (quite easily) to take care of asynchronous server communications, the guy from Encosia shows in a neat short article how to do this in jQuery - check it out.
Finally don't forget that if you use any postback controls, such as HTML Buttons, or ASPButton, ASPLink, the OnClientClick must contain something like "return false;" otherwise a page post-back occurs anyway as the server-side generated button click-event triggers. If you follow up these resources above, you will find that using AJAX instead of the update panel is actually very easy once you've done it a few times.
Conclusion
In conclusion update panel is nasty, it costs a lot of bandwidth and a lot of control is lost due to the nature Microsoft decided to hook it up with a pages's lifecycle. Some of that control can be regained by using the client side page-scrip-manager object as described on this page, however it doesn't resolve need for manual state-management of dynamically generated controls!
