ASP.NET Tips

ViewState does not suck...part 1

Scott Galloway — Tue, 09 Sep 2008 19:24:50 GMT

I was trawling through new posts on the ASP.NET blog site and came across this one from Tess (who is someone I should probably know but don’t…). What I found interesting (as well as the post which is excellent) was the first comment:

“When will MS simply drop the Viewstate completely? This is a good example of a solution to a problem that shouldn't be a problem to begin with. “

This got me to thinking, ViewState has gotten a really bad rap over the years (with notable exceptions). Let’s look at what ViewState actually is and why it might not be the villan it’s often painted out to be…

What is ViewState…at it’s simplest it’s a hidden field which contains data about the controls currently on the page. Really, that’s it…now it does this pretty cleverly, serializing a whole bunch of stuff into a Base64 encoded string (which can also be encrypted, validated etc…).

For those of us who wrote web apps back in the dark ages i.e., before ASP.NET, we remember the days where we had a bunch of hidden fields used to track changes in a page, and it was frankly a pain in the ass…it was far more transparent but a lot of grunt work just to track if a field’s value had changed / store some additional data in the page for use in postback. ViewState solves that problem pretty nicely actually.

So, what’s the problem people have? Two things:

1. people misuse it; it’s partly our fault and partly theirs.

From ‘Truly Understanding Viewstate’:

CASES OF MISUSE

a. Forcing a Default
b. Persisting static data
c. Persisting cheap data
d. Initializing child controls programmatically
e. Initializing dynamically created controls programmatically

Now, as I said it’s not entirely their fault…ViewState is enabled by default…if you bind a bunch of data to a DataBound Control then you’ll get a huge amount of ViewState serialized to and from the browser each time, it’s not that easy to figure out what having no ViewState will break / just enable it for certain controls and not others (which is what ControlState lets you do…just not for existing controls).
At it’s core the problem ViewState really has is that it’s a Leaky Abstraction; it’s ALMOST there but doesn’t quite hit the sweet spot nowadays…

So, how do you use ViewState correctly…what can you do to avoid the pitfalls?

Stay tuned!

Grrr...poor use of singletons and a very cool Generic Singleton pattern!

Scott Galloway — Thu, 01 May 2008 05:42:20 GMT

I posted earlier that I'm switching to blogengine.net, as part of this I've been fiddling around with the code (as is my way..I'll contribute back to the source when I've finished). One of my major pet hates is poor use of the singleton pattern, especially as there's a definitive article on the pattern in .NET and how to do it well. It's actually likely that this pattern is overkill in this case and a ReaderWriterLockSlim could be better (though it has it's own problems) . Anyway, on the assumption that a Singleton is the best choice here, let's look at the current code:

public static BlogSettings Instance

{

get

{

if (blogSettingsSingleton == null)

{

blogSettingsSingleton = new BlogSettings();

}

return blogSettingsSingleton;

}

If you look at the article I mentioned above you'll see that this is the version which is specifically called out as follows:

"the above is not thread-safe. Two different threads could both have evaluated the test if (instance==null) and found it to be true, then both create instances, which violates the singleton pattern. Note that in fact the instance may already have been created before the expression is evaluated, but the memory model doesn't guarantee that the new value of instance will be seen by other threads unless suitable memory barriers have been passed.'

The common 'best' singleton pattern (well, it's debatable...but generally the best...) is a lot more wordy (see version 5 in that article) so I was please to find this post on a Generic Singleton (actually this was posted a while ago on Codeproject)...really nice. In the Utils class I added this:

/// <summary>

/// Provides a Singleton implementation using Generics.

/// </summary>

/// <typeparam name="T">Type of singleton instance</typeparam>

public sealed class Singleton<T> where T : new()

{

Singleton() { }

public static T Instance

{

get

{

return Nested.instance;

}

class Nested

{

// Explicit static constructor to tell C# compiler

// not to mark type as beforefieldinit

static Nested() { }

internal static readonly T instance = new T();

}

The code for returning the instance then becomes:

public static BlogSettings Instance

{

get

{

return Utils.Singleton<BlogSettings>.Instance;

}

You have to also change the constructor for BlogSettings to public to allow this this to work which does let devs shoot themselves in the foot (by ignoring the singleton) and you of course have to balance the benefit agains that risk...