This post originated from an RSS feed registered with .NET Buzz
by Scott Hanselman.
Original Post: ASP.NET ViewState: Pox on mankind? Or clever like a fox?
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
A good friend of mine (who may or may not reveal himself by trackbacking this post)
emailed me recently, with reference to my
post on ASP.NET ViewState.
He had some interesting opinions, so here are some choice snippets reprinted with
this permission, with my commentary interlaced:
IMHO viewstate is the second worst piece of the .NET Framework. The worst being
"javascript:do_postback" instead of providing clean, lean and mean URLs. Oh wait,
they are related -- the latter is the necesary workaround for the former.
I think it's actually damned clever, and quite possibly neccesary. The HTTP/HTML
combination needed an eventing subsystem built on top of it. DoPostback() does
just that with support for Event Targets and Event Arguments. It's simple, supported,
and clean. POSTing data (rather than GETting) is needed, nay, required to move
stuff from place to place on browser-based web. I certainly can't be putting
on this crap in my URLs, can I? Believe me, I'm all about REST,
and I believe the REAL answer lies in both POSTs, and well designed URI/Ls.
Viewstate is bad because I can't set a bookmark to it. Instead of using viewstate,
developers who want to create great webapps should pass a querystring parameter for
read-only operations. The whole concept of doPostback should be abandoned altogether
and developers should instead look up the original HTTP specification which details
the ramification of GET vs. POST.
Phooey! :) Viewstate was needed to allow things like listboxes to POST not just
their currently selected item, but also ALL the other items. Otherwise, how
do I reconsitute my listbox on the next go-around? Better I pay a few BASE64'ed
bytes on the roundtrip than head back to the database.
ViewState was just a state bag, and as Brad notes in the
comments of the previous post, it can be "normalized" away with a key (I wonder
if they are hearing this and will hook it up to ASP.NET Session State in Whidbey?)
Now this I totally agree with. GETs and "hackable URLs" are totally
appropriate for an operation like this. But for a form that includes my credit
card info and full address, not so. Then add in dropdowns and database-backed
grids, then maybe a few buttons...aren't you wishing you had an eventing subsystem
and a way to reconstitute your controls? ;)
Second reason for why this whole thing (especially javascript:dopostback) is bad:
It doesn't allow me to "Open in new window". I use a tabbed browser and regularily
open links in new windows. I find more and more sites which just use ASP.NET and don't
handcode their URLs anymore leading to "forced-single-window-navigation."
True, I hate that also. But, to be clear, my mom, and most folks on the web,
don't care.
But let's get back to the topic: the creation of viewstate and
the associated necessity for doPostback instead of <a href=""> have created
a bunch of non-standard, non-userfriendly web applications.
Unfriendly is up for debate, but non-standard? I don't think so. Last
time I checked I had ASP.NET sites up running on 15 different browser variants using
doPostback happily and transparently. If there's a better way that will still
give me:
Server-side Events (onclick, onchange, etc)
Reconstitutes the state of my controls without requiring a call back to the datastore.
Then I'll be the first to code the HttpModules or whatever's required to make it happen.
Previous Topic
