Implementing state-full functionality behavior of custom object instances in ASP.NET

• Download demo project - 19.1 Kb

Foreword

I wouldn’t be able to write this article without Anastasia. You are wonderful, you are beautiful and you give me inspiration and new strengths. I love you.

Introduction

When you have some business logic that have to be implemented as a class and presented in your program code via an object of the corresponding class, it very often becomes a bare necessity to save the state of this object during aspx page postbacks. Some times it becomes hard to find an easy and convenient solution for this issue because of the stateless nature of HTTP. Hope that this article will help you to find some ideas on how to implement this functionality. The following solutions are based on the Singleton pattern. In short Singleton pattern allows you to manipulate objects (call its properties, methods) and guarantees that there is only one instance of this object presented at runtime.

Using the code

Solution I

This solution forces you to implement two static methods:

// returns singeltone instance from current page Session
public static ShonnCapushonClass GetSingletoneInstance (Page page)
{
 if (page.Session[ShonnCapushonClass.SessionId] != null)
 {
  return (ShonnCapushonClass)page.Session[ShonnCapushonClass.SessionId];
 }
 else
 {
  page.Session[ShonnCapushonClass.SessionId] = new ShonnCapushonClass ();
  return (ShonnCapushonClass)page.Session[ShonnCapushonClass.SessionId];
 }
}

and:

public static void SetSingletoneInstance (Page page, 
                        ShonnCapushonClass instance)
{
  page.Session[ShonnCapushonClass.SessionId] = instance;
}

In the aspx page code-behind, it will look like:

ShonnCapushonClass ShonnaObject = 
         ShonnCapushonClass.GetSingletoneInstance(this);
ShonnaObject.Name = "Tusenna";

When you do not need this object anymore, remove it from the session by calling:

ShonnCapushonClass.SetSingletoneInstance(this, null);

Solution II

This solution will be helpful when all actions of the object is encapsulated in a single aspx page. Let’s define a page property like this:

private ShonnCapushonClass PageShonnaObject
{
  get
  {
    return ShonnCapushonClass.GetSingletoneInstance(this);
  }
  set
  {
    ShonnCapushonClass.SetSingletoneInstance(this, value);
  }
}

In this case, manipulations can be easily done by referencing to the page property:

PageShonnaObject.Name = "PageTysena";
LabelShonnaName.Text = PageShonnaObject.Name;

When you need to reset the object state, just execute the following code:

PageShonnaObject = null;

Solution III

This is the most flexible solution that can be provided without the page instance and in this case your business object will be accessed from code until you explicitly destroy it or the user’s session expires. Also your object will be accessed from any page in your Web application: let’s define the Current property of your class like that:

public static ShonnCapushonClass Current
{
 get
 {
   if ( HttpContext.Current.Session[ShonnCapushonClass.SessionId] == null )
   {
     ShonnCapushonClass shonnCapushon = new ShonnCapushonClass();
     HttpContext.Current.Session[ShonnCapushonClass.SessionId] = shonnCapushon;
     return shonnCapushon;
    }
   else
   {
     return (ShonnCapushonClass)
             HttpContext.Current.Session[ShonnCapushonClass.SessionId];
   }
  }
 set 
 {
   HttpContext.Current.Session[ShonnCapushonClass.SessionId] = value;
  }
 }

After that your business object can be at any page of your application by implementing calls like:

ShonnCapushonClass.Current.Name = "CurrentTysena";

or

ShonnCapushonClass.Current = null;

Summary

In this article I’ve shared some ideas about managing business object state between aspx page postbacks and described some solutions for bypassing the constraint of the stateless nature of HTTP using session state and the Singleton pattern.