The Session object is extensively used for many projects, but it is often misused to the point of becoming unwieldy if it isn’t appropriately managed.
The ‘Traditional’ Management
The traditional method of referencing a session key is to use a string literal:
Session("SessionID") = 12345
Session("SessID") = 12345
Session("SID") = 12345
What’s wrong with the traditional method?
A better method
Instead of referencing a session key as a string literal, you should create a class that contains all of a project’s session keys. As you can see in the following example, session keys can be stored as individual string variables, or you can even create a structure that contains a group of related session keys.
Public Class SessionObjects Public Shared SessionID as String = "SessionID" Public Shared ShoppingCart As String = "ShoppingCart" Public Shared MoreSessionVars as String = "SessionVars" Public Structure SomePlugin Shared PluginPreference1 As String = "SomePlugin_PluginPreference1" Shared PluginPreference2 As String = "SomePlugin_PluginPreference2" Dim null End Structure End Class 'Usage: Session(SessionObjects.SessionID) = 12345 Session(SessionObjects.SomePlugin.PluginPreference1) = "False"

A session object addresses the main problems with string-literal session keys — it allows for code completion, which increases development speed and reduces typographical errors, and manages all the session keys in one place.
Although it may seem like extra work to create a class to contain all of your session keys, it’s going to save you a headache in the long-run, especially for anyone that might maintain your code in the future.
For those subscribed to The DotNetYuppie RSS feed, stay tuned because this article is one of several articles to come related to developing an efficient, standardized facade for enhanced project management.
Leave a Reply