Tuesday, September 25, 2007

Well...I do DEE-CLAY-AIRE...

First, I must apologize to my frequent blog-reader [singular] for the recent lack of new postings. Unfortunately, my company's firewall recently added www.blogger.com to their 'restricted list' which means no more workplace postings. Nevertheless...I will not be silenced! "The Man's" futile attempts to squelch my free-speech frenzy shall not succeed; my voice will continue to echo across the mountaintops of Blog-land!

Anyhoot...onto the bloggin' topic: The savage .NET 2.0 battle rages between declarative server control initiation versus programmatic server control initiation and maintenance.
Here is one such fellow blogger touting his preference for the pragmatic, programmatic methodology.

And here's my 2 cents: When first introduced to asp.NET 2.0, I, too, found the declarative server tags and DataSourceControl-populating wizards somewhat disconcerting, creepy, and a little too Dreamweaver for my taste. "I'm a real programmer", I kept thinking, "I've dredged my way through the ugliest, most-cryptic of programming coding (that's right, I've had to work with Prolog) and I certainly DON'T need any wizard to do my programming for me." I was suffering from what the professionals like to call 'Old-Skool-izm'.


Relatively soon, it became quite clear which side of the coin Microsoft's developers had contributed vastly superior resources towards planning, implementation and even documentation efforts; the declarative side. After MANY frustrating scenarios (and multiple blog postings) working with a variety of server controls in a stubborn, strictly programmatic manner, I found myself fixing many of the inexplicable, unintuitive server control symptoms and behaviors by simply switching to declarative mechanisms.


As time rolled on, and continued to plunge headfirst into the code-reducing, time-saving declarative devices, I found myself wondering why I had so fervently resisted them for so long. Certainly there are times when a programmatic method is necessary for a certain echelon of dynamic server control behavior, but when it's not; why write more code than I have to? And furthermore, why not allow Microsoft's framework to invisibly do the heavy lifting for me in terms of maintaining a control's state?


On that note, I recently discovered what I considered to be a somewhat obscure ViewState symptom of populating a server control programmatically rather than declaratively.
If you rely on a server control's view state to retain its data across postbacks, so that you’re not required to continuously re-load the control every time the page refreshes, asp will store your entire data set for that control in view state (that’s about 136 lines x 1024 characters worth of view state for a single DropDownList control populated with approximately 5000 records). This is because all changes made to server controls via the code-behind file are lumped in with asp’s interpreted "user-initiated control changes" and so are preserved within view state rather than stored server-side.

Alternatively, declaratively binding a server control to a DataSource object, such as a SQLDataSource or an ObjectDataSource, will store the control’s associated dataset server-side eliminating the size-able view state that will travel to/from server and users' browsers for each page request.

Similarly, any property setting changes made to controls in a programmatic manner, such as the control's styles, maxLength, databindings, etc will ALSO be recorded and maintained within the page's view state. Is one's view state really a consideration when we're talking about view state hogging rich server controls such as the GridView? Probably not, but it's food for thought.