Okay, I'm sure that at least half the ASP.NET developers that read this will wonder why I'm talking about the ASP.NET DataGrid instead of the new GridView. Well, the project I'm on will be based on ASP.NET 1.1 for some time to come. It's around 650 ASPXs, with a pretty complex/feature-rich architecture... it'll be a sizable project to convert it to ASP.NET 2.0 (at least to do it the right way).

So anyway... I just wanted to gripe about something with the DataGrid and its ViewState size. The application is basically an intranet application (might consider it an extranet), but users typically have direct T1 (or better) connections, so we were able to utilize ViewState to maintain control state without much worry. Don't get me wrong, we don't go throwing things into ViewState all willy-nilly, but we typically let the ASP.NET controls store their own stuff in ViewState, without turning ViewState off very often.

We do have a couple of screens that have been suffering from poor performance though. And after some investigation, I think the size of ViewState on the screens has a lot to do with it. I experienced upwards of 800KB of ViewState on one of the pages in Production. These screens have DataGrids that can become quite sizable, and they are responsible for all but 6K of the ViewState.

So knee-jerk reaction: turn ViewState off for the DataGrids. But wait... we have a template column in each of them that has a LinkButton control which uses CommandName/CommandArgument and the OnCommand event. With ViewState turned off, this doesn't work.

What is especially frustrating to me about this, is that back in ASP.NET 1.0 Beta 1, this actually DID work, at least from what I recall. I remember CommandArguments getting passed into the __doPostBack function and set as the __EVENTARGUMENT hidden field. Again, from what I recall, when ASP.NET 1.0 Beta 2 came out, this had been changed, and you had to rely on ViewState to get the CommandArgument.

So, in order to solve the problem for these screens, I had to do quite a bit of work. I created a new DataGridColumn control that puts a HyperLink into itself, and generates a postback link, passing the command name, command argument, and OnCommand function name into the __EVENTARGUMENT field. Then on postback, I have to examine the __EVENTTARGET and __EVENTARGUMENT to determine if one of these columns triggered the postback, and if so, use .NET Reflection to invoke the OnCommand function, passing the Command Event Arguments. It works well, and my ViewState was reduced from 800KB to 6KB. But boy that should've been baked into ASP.NET.

Now with ASP.NET 2.0, I don't know how this would react. Since the DataGrid is basically obsolete, I doubt that it would've worked much different with that control. And I have no idea how the GridView does this kind of stuff, but from what I've seen of the GridView thus far, I'm not real thrilled with it. It seems to have been designed from the ground up with the expectation that the developers using it can only use the designer to "write code". I need a power-user grid that is designed for complicated uses. But of course the commercial products out there for this kind of stuff have so many "bells and whistles" that they become bloated and buggy. I get the feeling that when I go to develop my first big ASP.NET 2.0 project, I will probably end up inheriting from the GridView and drastically overriding its behaviors. But then again, maybe I'll be surprised by what the GridView can do -- we'll just have to see.