Geeks With Blogs
Chris Breisch   .NET Data Practices
Search this Blog!

There's a good article by David Hay on this subject over at CodeProject.  When you read it, you'll no doubt have a "Well, duh.  Of course that's better.  Who didn't know that?"  moment.  I did.

So, why point it out?  Sometimes we don't do things that can help us, even though they're quite obvious.  We don't do them for many reasons, but I think the biggest is that we're not thinking about that particular item as an issue.  In this example, we've used session state for years, we know how to use session state, and we'll use it again while we're working on the "real" problem.

But if your foundation is faulty, you'll never have a sturdy structure.  This is one of those tools you can use to help stabilize your foundation.

Anyway, here's the problem in general.

Session State IS:

  • A good place to store and keep track of data for a user's session
  • Flexible.  You can store pretty much anything in session state

Session State IS NOT:

  • Type-safe -- All variables are strings
  • Scope-safe -- There's nothing preventing you from creating two session variables with different purposes and yet the same name
  • Typo-safe -- There's nothing preventing you from creating a session variable called "EditMode" and then trying to reference it as "EdtMode"

David suggests that we handle this by using the Facade pattern to facilitate type-safe/scope-safe/typo-safe interaction with our session state.  All session state activity would go through this facade, and never hit HttpSessionState directly.  We can even use the facade to create initializers for our session state variables.

Here are some of the benefits according to David:

    • Strong typing of what gets put into session variables.
    • No need for casting in code where session variables are used.
    • All the benefits of property setters to validate what gets put into session variables (more than just type).
    • All the benefits of property getters when accessing session variables. For example, initialising a variable the first time it is accessed.
    • An additional benefit of the facade design pattern is that it hides the internal implementation from the rest of the application. Perhaps in the future you may decide to use another mechanism of implementing session-state, other than the built-in ASP.NET HttpSessionState class. You only need to change the internals of the facade - you do not need to change anything else in the rest of the application

And it's not just with ASP.NET apps that we see this sort of behavior.  I'm working on a Windows Forms app right now that has some data stored in Name/Value pairs just like session state.  We could probably benefit from this approach as well.

I've given you enough information that you ought to be able to write this facade yourself, but read the article to make sure you glean the details that I've glossed over in my summarization.

Posted on Saturday, March 24, 2007 5:39 AM Architecture , ASP.NET | Back to top

Comments on this post: Manage Your ASP.NET Session Variables Using a Facade

# Link Listing - March 26, 2007
Requesting Gravatar...
telerik radEditor for Office SharePoint Server 2007 has been officially released! + Telerik for MCMS...
Left by Christopher Steen on Mar 26, 2007 11:25 PM

# Links (3/25/2007)
Requesting Gravatar...
.NET Consistent naming of PowerShell Cmdlets MbUnit: Unit Testing for People who Love Unit Testing FileWatch
Left by Member Blogs on Apr 25, 2007 10:43 PM

Your comment:
 (will show your gravatar)

Copyright © Chris J. Breisch | Powered by: