On a recent iteration of a project at work, we were analyzing our cache usage for several data analysis pages we have using ASP.net.  The usage of these pages evolved as we updated them with features, and in a pinch we were forced to turn off caching because of the hit to memory we were taking.  As we loaded more and more data into our database, and we had more and more users, more stuff was being cached, but we were not seeing benefits from the caching across users because each user was looking at different data.  Turning off the cache caused individual users to take a big performance hit when reloading the same report twice or making minor adjustments to the options, but we just couldn't justify the memory usage for that small percentage.

I decided the solution was a multi-level cache, where objects expired to lower levels, like from memory to high-speed disk, to slower disk, to db (really, I only want the memory and disk levels, but there's no need to limit it to that).  Unfortunately, there is no mechanism for injecting new behavior into the System.Web.Caching classes to accomplish that, which is a shame because they have already implemented the expiration and dependency code that would be the most complex part.

So, I'm faced with the possibility of creating my own caching framework, or tricking the System.Web.Caching classes to do my bidding using the existing mechanisms like dependencies (which is a possibility).

On another note, I implemented file-based ViewState quite successfully.  It was much more simple and straightforward to address issues like a user with multiple windows than any article led me to believe.  In doing so, I noticed some VERY annoying things about that ViewState persistence mechanism.  The normal behavior uses the LosFormatter to serialize the ViewState to base64 to be put inline with the html.  This is fine for storing ViewState inline, but if I'm serializing to files, I'd rather have the speed and efficiency of the BinaryFormatter.  The problem is that LosFormatter is special and doesn't play by the same rules as the other formatters in the framework (BinaryFormatter, etc).  Most of the built-in controls use Pair and Triplet to store their data in ViewState, but they aren't marked with SerializableAttribute which means that BinaryFormatter can't serialize them!  So I had to continue to use the LosFormatter, which bloats data horrendously.  I hope some of this is cleaned up for ASP.net 2.0.