The background:
I've seen a lot of articles lately about viewstate (well, in the last two weeks or so. I'm bad about keeping up with the rss) . Scott Mitchell recently published one article on MSDN all about the viewstate, and (among other things) showed how to send less viewstate. In it he also mentioned that Scott Galloway blogged on viewstate compression using bzip2. Also of note is the Flesk viewstate optimizer. All of these allow you to send less viewstate to the client, which means that you're saving bandwidth twice -- since the browser sends the Sviewstate back with the next request. For large pages with lots of viewstate, this can make a difference even on a LAN -- let alone those poor 56K modem users.
Now, I love these articles (and that looks like a good product), but they all take the same approach. While that's probably because it's the best one, I decided to try for the same result and take a different tack.
All of the above work by either having you override your page's “PersistViewStateToFileSystem” and call a method, or have you derive your page class from a base object they provide. All well and good, eh? Hey, the support is built into the framework!
The divergence:
I like a declarative approach. That is, I want to take an existing site, add on line to the web.config, and have it do what I want. After all, this is not per-page functionality I'm talking about here... it's a cross-cutting concern. Why modify all my pages to do it?
So I wrote one that just requires you to add an HttpModule (which takes copying a dll to your /bin dir, then adding three lines to your web.config. The module also requires just one more line to configure it). While this doesn't satisfy my "add one line" need, four lines is pretty close. And I don't have to modify anything else.
Presto! Add a module, and your viewstate shrinks. What could be easier? Now, before the parties start, let me warn you -- this is no magic bullet. GZipping the viewstate takes some time that could be used to download the viewstate... so where's the happy medium? Using a file store means you have lots of files and increased disk I/O. Using the Session or Application object mean more memory. And I can't generalize your database.
So this has the shotgun approach -- it can either compress the viewstate and leave it in-page (using #ziplib), it can save it to file, it can keep it in the application or session collections, or you can implement a (very, very simple) interface and do the work yourself.