HttpResponse.ApplyAppPathModifier

Se si usano le sessioni ASP .NET coockieless, ovvero sessioni in cui il SessionID viene inserito nell’url nella seguente forma:

/App/(S(avsbnbml2n1n5mi5rmfqnu65))/default.aspx

il metodo ApplyAppPathModifier della classe HttpResponse risulta estremamente utile, poichè, passandogli come parametro stringa un path virtuale, restituisce lo stesso path con il SessiondID inserito correttamente nell’url, sollevando lo sviluppatore dalla costruzione manuale dello stesso. Ciò risulta evidente ogni qual volta è necessario utilizzare url caricati dinamicamente.

Metodi virtuali nel costruttore

Tra le guidelines da seguire circa la scrittura del costruttore di una classe questa assume una certa importanza:

Evitare di richiamare all’interno di un costruttore un metodo virtuale.

Questa guidelines è dovuta al fatto che in presenza di un metodo che ridefinisce un metodo virtuale (ne fa l’override insomma), viene richiamato sempre il metodo esposto dalla classe derivata, ovvero il metodo più specifico della implementazione, a prescindere se il costruttore della classe che espone il metodo derivato sia stato richiamato.  L’esempio sotto, tratto dalla documentazione MSDN, chiarisce bene questo concetto.

La creazione della classe DerivedFromBad, cioè il richiamo del suo costruttore, provoca la chiamata immediata  al costruttore della sua classe di base, ovvero BadBaseClass, il quale prima inizializza una variabile (state) e poi richiama il metodo virtuale SetState. Peccato che poiche l’oggetto che si sta cercando di costruire (DerivedFromBad) ridefinisce il metodo SetState, all’interno del costruttore della classe BaseClass il metodo effettivamente chiamato è l’implementazione fornita dalla classe DerivedFromBad, e non quella della classe base BadBaseClass. L’esecuzione  del metodo ridefinito SetState avviene a prescindere se il costruttore della classe derivata sia o no stato richiamato. In questo caso, poiche non  viene richiamato, l’inizializzazione della variabile state non  avviene ed il suo contenuto resta fermo a quello impostato dalla classe base, ovvero “BadBaseClass“.

 public class tester
 {
     public static void Main()
     {
         DerivedFromBad b = new DerivedFromBad();
     }
 }
      
 public class BadBaseClass
 {
      protected string state;
      public BadBaseClass()
      {
          state = "BadBaseClass";
          SetState();
      }
      public virtual void SetState()
      {
 
      }
 }
   
 public class DerivedFromBad : BadBaseClass
 {
      public DerivedFromBad()
      {
        state = "DerivedFromBad ";
      }
      public override void SetState()
      {
        Console.WriteLine(state);
      }
 }  

Snippet Code

Gli Snippet Code possono davvero far risparmiare tempo di sviluppo, soprattutto su operazioni ripetitive. Visual Studio, come è noto, fornisce un add-in per la gestione degli stessi su PC, e codificati in un file xml. Chi come me non usa sempre lo stesso PC per lavorare è costretto a sincronizzare gli snippet code su tutti i PC su cui sviluppa, operazione molto noiosa e anche molto soggetta ad errori. Sarebbe comodo in questi casi non avere il repository in  locale, ma averli centralizzati all’esterno.

<Code:Keep> fornisce appunto uno storage centralizzato  da cui attingere snippet code suddivisi per categoria ed in cui inserire i propri, ovviamente rendendoli usufruibili anche agli altri visitatori del sito, previa registrazione. Inoltre, viene messo a disposizione il download di un add-in per Visual Studio 2008, ovviamente gratuito, che permette di consultare ed utilizzare gli Snippet Code presenti nel sito direttamente dall’IDE, senza neanche aprire il browser.