Jeff's Blog

This is the second to last post in this series, and basically this is just going to be some trace.axd output comparing a WebMethod populated Modal Dialog with an Update Panel generated dialog. Instead of the really basic UI I've been using to prototype some of this code, I'm going to use a simple Grid/Detail setup using an asp:repeater combined with the modal popup to view the details. I'm going to use a Customer/Location Domain/DAL setup that I've got floating around (see here for what I'm talking about). I'm not going to include code in this post, there's too much to be meaningful, instead I've decided to make my next set of blog posts about creating a canned set of Domain objects, with some nice static data seeding helpers.

I'd still like to emphasize that this is not a production level code to production level code comparison, rather just a stake in the ground to get an idea of the cost of doing things the long way vs. the short way. The thing I've realized is that the easier that the .Net framework makes things, the harder it is to get something to work just the way you need it to. Almost without exception every portion of chocolaty code goodness that I sample from the .Net factory suffers from the problem of trying to be all things to all people. 8 out of 10 times this might just be what's needed, but the really fun, challenging projects just aren't able to take advantage of the sugar that's already made. This is not surprising, nor in anyway a shortcoming of the .Net framework, just a reminder that there will always be a need for skilled coders who like looking over the side of the bridge.

Nuts and bolts:

This sample project puts the WebMethod based Modal approximately 2-3 times faster than the UpdatePanel. This is completely arbitrary of course, because the only real determining factor is the amount of time it takes to render the entire page vs. the actual content required.

Here's a screen shot of the app with the first of two modal dialogs showing. Basically it's a list of customers, that opens a modal with a list of Locations, that allows you to select a single location to get it's details. There are 2 WebMethods GetLocations, and GetLocationDetails, and for the UpdatePanel version, there's a ControlLoader that knows how to select the proper content. Again this app is very simple, and the page render times would be more than adequate for either approach on any production page I've seen, but this again is about understanding what we are working with.

Here's the timings from the WebMethod approach:

Here's the UpdatePanel Timings:

Really the difference in a typical page might be not much worse than this, on the other hand a page that's rich with content might present an entirely different story with several hundred milliseconds being burned on unneeded tasks. In reality though, some good design work could easily mitigate the overhead of the full page render associated with an update panel. Yes this would require target specific coding, but at least in my example here, so does the WebMethod based approach. The number one thing I that's a true benefit of using WebMethods it's a thorough understanding of the process, the what, why how of making a responsive web base application, but more on that on Part 9 of this series.