In my last post I gave an example of using the Proxy Design Pattern to manage your ASP.NET Session. In this post I wanted to refine that proxy class through some refactoring and add some additional functionality to it that remove Session variables and also allow us to use the proxy to clear or abandon the Session as a whole. We will also create a mechanism for grouping Session variables into related objects in the SessionProxy.
First I want to add a private property that will allow me to eliminate some of the verbosity in my code. I’ll add a private static property that encapsulates the current HTTPSessionState object. We can then use that property to refactor our other properties so they are more readable.
1: private static HttpSessionState Session { get { return HttpContext.Current.Session; } }
Next we’ll add some code into our properties that will check for the value being set and remove the Session variable from the Session object if necessary. As an example I’ll use a new Property of type String.
1: public static String CategoryName
2: {
3: get
4: {
5: if (Session[CATEGORYNAME] == null) { return String.Empty; }
6: return (String)Session[CATEGORYNAME];
7: }
8:
9: set
10: {
11: if (String.IsNullOrEmpty(value)) { Session.Remove(CATEGORYNAME); }
12: else { Session[CATEGORYNAME] = value; }
13: }
14: }
Now I want to add a few methods to allow me to use the SessionProxy to Clear the current Session or Abandon it.
1: #region Methods
2:
3: public static void Clear() { Session.Clear(); }
4:
5: public static void Abandon() { Session.Abandon(); }
6:
7: #endregion
At this point I feel that I have a pretty good proxy class that allows me to leverage my ASP.NET Session in a strongly type manner and to easily see what I am storing in the Session and what their types are.
However, in using this solution in a production application I have found that my list of properties has grown longer than I would like. There were close to two dozen at last count and all the Session variables have not been migrated to use the proxy. I found myself increasingly tired of seeing all those properties each time I accessed the class. On top of that some of the names were getting rather long in an effort to give them meaningful names. To resolve this I implemented several properties on the SessionProxy that were child proxy objects. To make things a bit easier I created a base class called SessionProxyChildProxyBase. Here’s the code in full for that base class.
1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Web;
5: using System.Web.SessionState;
6:
7: public abstract class SessionProxyChildProxyBase
8: {
9:
10: #region Properties
11:
12: protected HttpSessionState Session { get { return HttpContext.Current.Session; } }
13:
14: #endregion
15:
16: }
You will note a few points on this class. Unlike the SessionProxy class the SessionProxyChildProxyBase class is an abstract class. We don’t want to allow others to implement this base class outside of our library so that the SessionProxy class now becomes a proxy for this class as well as for the ASP.NET Session. It also contains a protected Session property that will facilitate a decrease in code verbosity.
Now we will leverage this base class and create derived classes that will contain related properties. In your application you may provide a central location for entering search criteria but you pass those criteria via the Session to a page that actually displays the search results. Let’s create a child proxy class to organize the various values being passed.
1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Web;
5:
6: public class SearchSessionProxy: SessionProxyChildProxyBase
7: {
8:
9: #region Fields
10:
11: private const String SEARCHTEXT = "SearchText";
12: private const String SEARCHTYPENAME = "SearchTypeName";
13:
14: #endregion
15:
16: #region Properties
17:
18: public String Text
19: {
20: get
21: {
22: if (Session[SEARCHTEXT] == null) { return String.Empty; }
23: return (String)Session[SEARCHTEXT];
24: }
25:
26: set
27: {
28: if (String.IsNullOrEmpty(value)) { Session.Remove(SEARCHTEXT); }
29: else { Session[SEARCHTEXT] = value; }
30: }
31: }
32:
33: public String TypeName
34: {
35: get
36: {
37: if (Session[SEARCHTYPENAME] == null) { return String.Empty; }
38: return (String)Session[SEARCHTYPENAME];
39: }
40:
41: set
42: {
43: if (String.IsNullOrEmpty(value)) { Session.Remove(SEARCHTYPENAME); }
44: else { Session[SEARCHTYPENAME] = value; }
45: }
46: }
47:
48: #endregion
49:
50: #region Constructors
51:
52: internal SearchSessionProxy() { }
53:
54: #endregion
55:
56: }
Now we need to add some code to our SessionProxy class to leverage this new class. The first task is to add a private static field of type SearchSessionProxy.
1: #region Fields
2:
3: private static SearchSessionProxy _searchProxy = new SearchSessionProxy();
4:
5: #endregion
Next we will create the property to access the field.
1: public static SearchSessionProxy Search { get { return _searchProxy; } }
And that’s it! Now we call utilize our SessionProxy with our new child proxy classes for organization and grouping so that we can doing something like this in our web app code…
1: public void DoSomething()
2: {
3: SessionProxy.Search.Text = "Search Text entered by user";
4: SessionProxy.Search.TypeName = "Product Search";
5: SessionProxy.ProductID = 0;
6: Response.Redirect("SearchResults.aspx");
7: }
Tags: .net, architecture, asp.net, best practices, tips & tricks