A piece of UIP

Nowadays, I in fact deal with web applications, i have the opportunity to construct several and i learn some things about how you do things.

First i read about layers, and specially presentation layer, wich is the most expensive layer. Where you have to fight with HTML and if you have good luck with ASP.NET, an event oriented implementation that will be adopted by the other technologies soon or later, so dont worry. There is a special thing wich is called "the state", the only place confortable to store data wich you have to decide to store in a server state, or database or in memory, or wherever... and works ok.

There is a sublayer of the presentation layer, that is not commonly used "User Interface Process" or UIP, in this layer you have process objects for two things: 1) orchestate flow of pages, to avoid burn redirects in web pages and 2) handle state of the process, in order to mantain data about the currently process (supported in session of course). You can think about a process as a set of pages to do a task, and a UIP object to support transition of pages and a temporal data store.

When you implement this, the pages who always points to the business layer, instead will point to the UIP objects and UIP objects points to business (like an intermediate layer), but this is really expensive unless you decide to use a framework.

For ASP.NET this is too tricky, there are a "User Interface Application Block" wich uses Windows Worflow Fundation and a lot of instrumentation libraries, making a good implementation but an overhead for medium proyects from any point of view.

So... what could you do. My advice is to continue burning page transitions, and use a piece of UIP concept wich is the encapsulation of the state. It says that you should encapsulate the state of the process in an serializable object instead of throwing objects directly in session. Well this is good, because you can handle this state object like a process state, you can restart it, or clean it, accessing a single object, and additionally you dont have to deal with a lot of keys to map your data in session.

Well there are more things i can say about this layer, but i will show some implementation. First i use a base class, where is implemented the common funcionallity:

[Serializable]
public class StateBase<T> where T : new()
{
  public static T Current
  {
    get {
      string key = typeof(T).Name;
      return (T)(HttpContext.Current.Session[key] != null ?
        HttpContext.Current.Session[key] :
        HttpContext.Current.Session[key] = new T());
    }
  }

  public void Save()
  {
    string key = this.GetType().Name;
    HttpContext.Current.Session[key] = this;
  }
}

Then i implement as many State objects as i need (a clean implementation):

[Serializable]
public class AccessLevelState : StateBase<AccessLevelState>
{
  public int? IdAccessLevelToModify = null;
}

And, thats it.... some kind of static inheritance for Current method, a bit useful
Maybe you asking yourself about memory handling... Well you could put a clean method in the base class, but to be honest, not always you can clean the state cause in web applications, you never know where user are going to make a click. But maybe later i talk about it....