ASP.NET

La comunicazione

La comunicazione HTTP è incapsulata fondamentalmente in due oggetti:

• Request: incapsula la richiesta del client. Ad esempio fa accedere agli array contenenti i parametri inviati:
  • Cookies;
  • QueryString;
  • Form;
• Response: incapsula la risposta del server. Ad esempio
  • si può eseguire un redirect con : Response.Redirect(www.miosito.it);

quando una pagina contiene un form che richiama se stessa, e vogliamo distinguere se, al momento dell'apertura della pagina, la chiamata viene da detto form, si utilizza la proprietà IsPostBack della pagina.

Creazione di un web site

Le opzioni per creare un web site sono (alla voce Web location):

• File System: si crea in locale, oppure su un drive di rete che può essere mappato su una cartella condivisa dal server web o via HTTP (con il comando net use * http://www.miosito.it) se il server ha autorizzato il ruolo di WebDAV authoring al vostro utente.
• FTP: si crea in remoto via FTP;
• HTTP: si crea in remoto via HTTP però il server deve avere il ruolo WebDAV Publishing o le Front Page Server Extensions 2002.

Si può creare un Web Site o una Web Site Application, la differenza è che nel secondo caso:

• si genera un file di progetto
• si crea una unica DLL in compilazione quindi:
  • non è possibile mescolare linguaggi diversi
  • modificare il codice in debug senza interromperlo e ricompilare
  • modificare un singolo file e farne il deploy sul server dopo il deploy dell'intera applicazione
  • non è possibile fare il deploy solo dei sorgenti e sfruttare la compilazione a runtime di IIS
• è possibile stabilire dipendenze multiple tra progetti

Ciclo di vita ed eventi di un'applicazione web

1. Applicazione: durante la sua esecuzione sul server l'applicazione scatena alcuni eventi, che possono essere gestiti con degli handler implementati nel file Global.asax:
   1. Application_Start
   2. Application_End
   3. Application_Error
   4. Application_LogRequest
   5. Application_PostLogRequest
2. Sessione: durante la sessione utente l'applicazione scatena alcuni eventi, che possono essere gestiti con degli handler implementati nel file Global.asax:
   1. Session_Start
   2. Session_End
3. Pagina (in ordine di esecuzione):
   1. PreInit : è il primo evento, è adatto per gestire MasterPage e aggiungere dinamicamente controlli per pagine senza MasterPage;
   2. Init : avviene dopo che tutti i controlli sono stati inizializzati e quindi e adatto per modificarnei valori, è in oltre adatto per aggiungere dinamicamente i controlli alla pagina (se ha MasterPage è meglio farlo qui);
   3. InitComplete : avviene dopo che l'inizializzazione della pagina e di tutti i suoi controlli;
   4. PreLoad : avviene prima che il viewState sia stato caricato;
   5. Load : avviene dopo che il viewState è stato caricato;
   6. Eventi del controllo che ha scatenato il postBack : se vogliamo che tutti scatenino ogni volta un postBack occorre settare la proprietà "AutoPostBack" a true;
   7. LoadComplete : avvine quanto tutti i controlli sono stati caricati;
   8. PreRender : avviene prima che i viewState sia salvato;
   9. SaveStateComplete : avviene dopo che il viewState è stato salvato;
   10. Render (è un metodo non un evento);
   11. Unload : viene lanciato per ultimo, quindi è edatto per rilasciare risorse.
4. Controlli : i controlli inseriti nellapagina a design time scatenano gli stessi eventi della pagina contemporaneamente ad essa, e i loro sottocontrolli a loro volta fanno lo stesso, mentre se aggiungiamo dei controlli dinamicamente, essi scatenano detti eventi in modo sequenziale.

Gestione dello stato

I dati di una pagina vengono eliminati  alla fine del render di pagina. Se volessimo riutilizzarli dobbiamo utilizzare uno dei seguenti meccanismi offerti da .NET per memorizzare lo stato della pagina:

1. Client-side: lo stato viene memorizzato dal client quindi non consuma memoria sul server e consente l'utilizzo di server multipli.
   1. View sate : è una collezione di oggetti utilizzata da .NET per conservare il contenuto dei controlli tra una richiesta e l'altra della medesima pagina. va usato quando implementiamo dei custom controls o quando semplicemente vogliamo consevare un dato da una richiesta all'altra. Occorre castare gli oggetti quando li recuperiamo. Ad Es: string s = "ABC";ViewState["vss"] = s; string s2 = (string)ViewState["vss"] ;
   2. Hidden Fields : i campi nascosti sono comunque dei controlli e quindi rientrano nel meccanismo del viewstate.
   3. Session state : è una collezione di oggetti utilizzata da .NET per conservare gli oggetti per tutta la durata della sessione utente (visita singola). Occorre castare gli oggetti quando li recuperiamo. Ad Es: string s = "ABC";Session["vss"] = s; string s2 = (string)Session["vss"] ;
   4. Cookies : utilizzando i cookies i dati vengono memorizzati sul computer dell'utente e divengono disponibili anche nelle visite successive. Ad esempio se volessimo memorizzare un valore dovremmo usare Response.Cookies.Add(new HttpCookie("chiave",valore)) e Request.Cookies["chiave"].Value per recuperarlo. I valori letti vanno sempre codificati con Server.HtmlEncode oppure vanno utilizzate conversioni di tipo per evitare l'esecuzione di script nocivi. In oltre si può definire
      1. la durata della validità : Response.Cookies["chiave"].Expires = DateTime.Now.AddDays(1);
      2. la sezione del sito per il quale sarà considerato il cookie: Response.Cookies["chiave"].Path = "/sottodirectory";
      3. il dominio di validità : Response.Cookies["chiave"].Domain = "miosito.it";
      4. Array di valori : a volte non è possibile memorizzare più di 20 cookies per sito, quindi si possono memorizzare più valori nello stesso cookie utilizzando delle sottochiavi: Response.Cookies["chiave"]["sottochiave1"]= valore1; Response.Cookies["chiave"]["sottochiave2"] = valore2;
   5. Query strings : i campi vengono valorizzati direttamente nella URL, aggiungendo "?" all'indirizzo e successivamente concatenando "chiave=valore" in una sequenza separata da "&". I valori sono successivamente reperibili con Request.QueryString["chiave"]. I valori letti vanno sempre codificati con Server.HtmlEncode  oppure vanno utilizzate conversioni di tipo per evitare l'esecuzione di script nocivi;
2. Server-side: lo stato viene menorizzato sul server quindi è più sicuro per dati sensibili e riduce il consumo di banda.
   1. Application state : è una colezione di oggetti che vivono per tutta la durata dell'applicazione, sono reperibili con la solita sintassi valore = (tipo)Application["chiave"] e memorizzabili con Application["chiave"] = valore. Esistono in oltre gli eventi legati all'applicazione void Application_Start(object sender, EventArgs e) {} e void Application_End(object sender, EventArgs e) {} utili per inizializzare valori o rilasciare risorse. Infine occorre utilizzare Application.Lock(); prima di scrivere un valore e Application.UnLock(); appena finito per evitare le scritture concorrenziali di più sessioni.
   2. Session state : è una colezione di oggetti che vivono per tutta la durata della sessione utente, sono reperibili con la solita sintassi valore = (tipo)Session["chiave"] e memorizzabili con Session["chiave"] = valore. Esistono in oltre gli eventi legati all'applicazione void Session_Start(object sender, EventArgs e) {} e void Session_End(object sender, EventArgs e) {} utili per inizializzare valori o rilasciare risorse. Di default, se il client lo permette, .Net tiene traccia della sessione sul client scrivendo in un cookie chiamato "ASP.NET_SessionId" l'identificativo della sessione, se il client non lo permette .Net utilizza la URL concatenando l'identificativo nel path, al livello per il quale avrebbe avuto validità il cookie. La sessione ha tre diverse modalità per essere memorizzata sul server:
      1. InProc : viene memorizzata in memoria sul server; 
      2. StateServer : viene memorizzata da un servizio dedicato che può risiedere su un altro server;
      3. SQLServer : viene memorizzata su database SQL;
      4. Custom : permette di specificare un provider personalizzato;
      5. Off : viene disabilitata.