La nuova architettura di ASP.NET 2.0

L'architettura di questa nuova versione di ASP.NET ha spunti decisamente interessanti. Quello meno enfatizzato, ma a mio modo di vedere davvero importante, è lo stesso per il quale IIS 7 vanta ottime credenziali: la possibilità di far processare qualsiasi richiesta ad ASP.NET, ma lasciar poi gestire il risultato finale alla risorsa effettiva.

L'esempio è sempre lo stesso. Se utilizzare IIS 6 ed ASP.NET 2.0, potete mappare tutti i file, attraverso la console di gestione di IIS, perché passino attraverso ASP.NET, lasciando invariati i mappings sulle singole estensioni. Certo, questo ha un costo, ma i vantaggi che ne derivano sono immensi.

Grazie alla nuova pipeline di gestione della risposta, ASP.NET prenderà in carico la stessa e solo se necessario interverrà, lasciando di fatto l'esecuzione della risorsa all'ISAPI extension specifica.

Nel caso di una pagina ASP questo vuol dire che se avete protetto l'intera directory con la FormsAuthentication non dovrete fare nient'altro, perché ASP.NET intercetterà la richiesta e se il ticket di autenticazione non è presente provvederà a fare il redirect sulla pagina designata per il login!

Ovviamente perché questo sia possibile è anche necessario mappare, nel web.config, tutte le richieste in modo che vengano gestite da una nuova classe, che si chiama DefaultHttpHandler, che ha come comportamento appunto quello di provare ad eseguire, attraverso ISAPI, la richiesta con il proprio handler di default, senza dover usare StaticFileHandler, come nella 1.x, che limita l'applicazione di questa tecnica a ben pochi scenari.

Non ci sono limitazioni particolari, proprio come con IIS 7, perché DefaultHttpHandler è stato pensato proprio per scenari come questo, consentendo dunque l'utilizzo di Membership APIs anche con risorse non-ASP.NET, ma garantendo al tempo stesso che la richiesta venga processata dall'handler specificato.

Altra interessante novità è quella degli HttpListener.
In pratica si tratta di classi specifiche pensate per poter interfacciare ASP.NET con http.sys, ovvero la parte che in IIS 6 è responsabile per richieste e risposte. L'utilizzo di un HttpListener è semplice: basta creare una classe, ad esempio un HttpModule, che inizializzi la classe HttpListener, aggiungendo gli indirizzi sulla quale deve restare in ascolto. Ovviamente è possibile anche fare in modo che il Listener sia in ascolto su porte personalizzate, scenario che torna utile quando si vuole creare un sistema di notifiche che sfrutti il web come mezzo di trasporto.

Questo sistema, ad esempio, rende possibile il colloquio per processi esterni che girano sullo stesso server, che possono sfruttare ASP.NET come "ponte", un po' come Remoting, ma con il sostanziale vantaggio di richiedere meno passi complessi da seguire nella fase di setup.

Ed in effetti gli HttpListener sono proprio alla base di Indigo, anche noto come Windows Communication Foundation, che a differenza dei web services ASMX, che sono eseguiti all'interno di IIS, sfrutta proprio questo concetto per poterne sfruttare i servizi girando però in un contesto separato. O ancora dal nuovo sistema di notifiche che SQL Server 2005 utilizza per la dipendenza della cache da una resultset, inviando dunque gli avvisi di invalidazione di un elemento in cache quando i dati cambiano e rendendo dunque tutto automatizzato ai nostri occhi.

Infine, di interesse anche i nuovi build provider. Un build provider è un tipo particolare, implementato in una classe, che è registrato per costruire al volo un risultato partendo da un file, attraverso regole ben precise, espresse con codice. Un build provider è associato ad un'estensione specifica e quando un file di questo tipo è inserito nella directory app_code posta sotto la root dell'application, che è riservata ai file di codice sorgente, ASP.NET invoca il build provider registrato nel web.config per costruirne al volo il risultato, attraverso la compilazione. Un esempio di questo approccio sono i file .wsdl o .xsd, utilizzati per i proxy dei Web Services o per i DataSet tipizzati, ma ovviamente è possibile crearne di personalizzati ed ancora più ovvio è che ASP.NET utilizza questo meccanismo anche internamente, per le proprie risorse.

Directory speciali

Abbiamo già visto che esiste una directory particolare, chiamata app_code, che può contenere file sorgente che sono compilati al volo.

In realtà, oltre alla ormai classica directory bin, bisogna fare attenzione a non dare mai un nome tra quelli riservati alla nostre directory, altrimenti con buone possibilità qualcosa non andrà come ci saremmo aspettati. Non c'è da temere, comunque, dato che i nomi scelti non sono così comuni:

• app_code: ci vanno file sorgenti, che saranno compilati al volo;
• app_globalresources: contiene le risorse globali;
• app_localresources: contiene i file di risorse locali;
• app_webreferences: le reference a web services;
• app_data: è una directory in cui inserire i file di dati dell'applicazione, come file XML o database, dato che il runtime li protegge in automatico dal download;
• app_browsers: contiene le definizioni locali dei browser, utilizzate dal meccanismo di adaptive rendering;
• app_themes: contiene i temi dell'applicazione, argomento su cui ci soffermeremo con un articolo specifico.

VS 2005, in presenza di queste directory, è in grado di aiutarvi nella creazione dei file che sono più adatti a ciascuna tipologia e, come in altri casi, anche in questi scenari l'Intellisense è in grado di attingere alle informazioni presenti in queste directory speciali, aiutandoci nella costruzione delle nostre applicazioni.

Contenuti dell'articolo

• Pagina 1
  • Cronaca di una versione di successo
  • Le novità in VS 2005
• Pagina 2
  • La nuova architettura di ASP.NET 2.0
  • Directory speciali
• Pagina 3
  • Provider Model Design Pattern
  • C'è sempre e solo una form per pagina, ma...
• Pagina 4
  • Compilation Model, precompilazione e nocompile mode
  • Dove scaricare il runtime e l'SDK
  • Conclusioni
  • Tutti gli articoli dello speciale su ASP.NET 2.0