Para continuar con lo que otros han dicho. Tiendo a tener dos capas:
La capa central. Esto está dentro de una DLL que se agrega a casi todos los proyectos de aplicaciones web . En esto tengo una clase SessionVars que hace el trabajo pesado para los captadores / definidores de estado de sesión. Contiene código como el siguiente:
public class SessionVar
{
static HttpSessionState Session
{
get
{
if (HttpContext.Current == null)
throw new ApplicationException("No Http Context, No Session to Get!");
return HttpContext.Current.Session;
}
}
public static T Get<T>(string key)
{
if (Session[key] == null)
return default(T);
else
return (T)Session[key];
}
public static void Set<T>(string key, T value)
{
Session[key] = value;
}
}
Tenga en cuenta los genéricos para obtener cualquier tipo.
Luego también agrego Getters / Setters para tipos específicos, especialmente cadenas, ya que a menudo prefiero trabajar con string.Empty en lugar de null para las variables presentadas a los usuarios.
p.ej:
public static string GetString(string key)
{
string s = Get<string>(key);
return s == null ? string.Empty : s;
}
public static void SetString(string key, string value)
{
Set<string>(key, value);
}
Y así...
Luego creo envoltorios para abstraer eso y llevarlo al modelo de aplicación. Por ejemplo, si tenemos datos del cliente:
public class CustomerInfo
{
public string Name
{
get
{
return SessionVar.GetString("CustomerInfo_Name");
}
set
{
SessionVar.SetString("CustomerInfo_Name", value);
}
}
}
¿Captas la idea cierto? :)
NOTA: Solo tuve un pensamiento al agregar un comentario a la respuesta aceptada. Asegúrese siempre de que los objetos sean serializables cuando los almacene en Session cuando utilice un servidor de estado. Puede ser muy fácil intentar guardar un objeto usando los genéricos cuando está en una granja web y se dispara. Implemento en una granja web en el trabajo, así que agregué controles a mi código en la capa central para ver si el objeto es serializable, otro beneficio de encapsular los captadores y configuradores de sesión :)