Ik zie in code geregeld dat het Session object op allerlei plaatsen gebruikt wordt, met name in pagina's en controls, als volgt:

public void Page_Load(object sender, EventArgs e)
{
    Session["MySessionVar"] += 1;
}

public void Page_PreRender(object sender, EventArgs e)
{
    Label1.Text = Session["MySessionVar"].ToString();
}

Dit is om meerdere redenen niet aan te raden:

1. Omdat de collectie loosely typed is, is er geen compile-time check bij het benaderen van de elementen in de collectie. Het is daarom heel makkelijk om een typfoutje te maken, waardoor je tegen het verkeerde object aan praat.
2. Door elementen in het Session object te stoppen in de pagina, is er geen centrale administratie van de namen (keys) die in gebruik zijn.

Je kunt beide zaken oplossen door een centraal object te maken waarmee je de elementen in het Session-object benaderd, als volgt:

/// <summary>
/// Strongly typed toegang tot Session-object.
/// </summary>
internal static class TypedSession
{
   public static int MySessionVar
   {
      get
      {
         object o = HttpContext.Current.Session["MySessionVar"];
         if(o == null) return 0;
         return (int)o;
      }
      set
      {
         HttpContext.Current.Session["MySessionVar"] = value;
      }
   }
}

Merk op dat bij de get-accessor eerst gekeken wordt of het object null is. Dit is nodig omdat een int niet null mag zijn. Voor objecten waarvoor dat wel mag kun je desondanks besluiten dat er een standaardwaarde moet zijn, bijvoorbeeld een nieuw object.

Deze methodiek werkt ook uitstekend voor de Request.QueryString collectie en meer van dat soort collecties die je normaal gezien loosely typed gebruikt. Die zal je niet zo snel centraliseren, omdat het juist op een bepaalde pagina van toepassing is, maar daarmee strongly typed kunnen werken is nog steeds minder foutgevoelig. Bovendien hoeft de ontwikkelaar niet te weten waar de data vandaan komt.