ASP.NET (chiamato in una prima versione ASP+) è più di un semplice upgrade di Active Server Pages, la soluzione Microsoft per la realizzazione di siti dinamici.

Chi ha esperienza di sviluppo con questa tecnologia ne ha già ben chiaro i vantaggi e le lacune. A fronte di una elevata semplicità nella stesura del codice (un programmatore Visual Basic è produttivo con ASP dopo pochi giorni), esiste una difficoltà quasi cronica nella correzione degli errori (debugging). I documenti ASP, inoltre, sono tutt’altro che prestazionali, poiché richiedono l’esecuzione di un interprete di comando ad ogni accesso.

Microsoft ha lavorato tre anni per questa nuova versione, riscrivendo completamente il codice originario di ASP: il risultato è una piattaforma di lavoro più efficiente e decisamente più orientata agli oggetti, tanto che in ASP.NET i tag possono essere generati lato server piuttosto che lato client.

Le Web Forms

Fino ad oggi, chi ha intrapreso la programmazione Web migrando da un ambiente di sviluppo tradizionale qual è Visual Basic, ha dovuto rinunciare a malincuore a molte opportunità.

Come prima cosa, i tag HTML non sono dei veri controlli, e come tali non dispongono di un puro modello di programmazione ad oggetti. Inoltre, il codice HTML è molto spesso “amalgamato” con il contenuto della pagina: una modifica alla struttura del sito comporta anche una ristrutturazione dell’informazione.

Per ridurre questi effetti collaterali, Microsoft ha introdotto in ASP.NET una libreria di oggetti, chiamata Web Forms, con lo scopo di agevolare e rendere più chiara la stesura di codice all’interno di una pagina dinamica. L’idea è molto semplice. E’ possibile specificare un tag nella forma:

Quando il processore ASP.NET incontra il tag, lo trasforma nel corrispettivo HTML. Il vantaggio è che questi controlli dispongono di un certo numero di proprietà, metodi ed eventi che usano una nomenclatura coerente e modificabili da codice.

Inoltre, nel generare la pagina, il processore ASP.NET è in grado di riconoscere il browser dell’utente: può di conseguenza generare una pagina HTML che ne utilizzi solo le caratteristiche supportate.

Come ulteriore vantaggio, con questo modello ad oggetti è notevolmente semplificata la convalida dei dati provenienti dall’input degli utenti, che è così gestita sia lato client sia lato server. Con le Web Forms è anche possibile “simulare” il mantenimento di stato tra le pagine, con le cosiddette “postback form”.

Aumentano i linguaggi di sviluppo

La presenza del .Net Common Language Runtime consente allo sviluppatore l’utilizzo di una platea teoricamente infinita di linguaggi per la scrittura di pagine ASP.NET. Usare un linguaggio od un altro risulta indifferente, visto che si usano le classi presenti nelle librerie .NET. In questo modo è possibile adottare Visual Basic, C# oppure ad esempio Fortran: si userà il linguaggio con il quale si è più produttivi o quello che rappresenta lo standard aziendale. Il Common Language Runtime si comporta quindi da strato di interfaccia tra la complessità del sistema operativo (e delle sue API – Application Program Interfaces) e il linguaggio.

Con ASP.NET Microsoft da inoltre l’addio a Visual Basic Script, che è sostituito da un pieno supporto per Visual Basic, un suo sovrainsieme. Come conseguenza, Visual Studio .NET (il successore di Visual Studio 6) non contiene due ambienti di programmazione, uno per Visual Basic e uno per la stesura di codice ASP (Visual Interdev), ma un solo strumento integrato di sviluppo per tutti i linguaggi.

Le pagine ASP.NET sono compilate

L’unica soluzione all’inefficienza del codice interpretato è la sua compilazione. Una pagina ASP.NET è creata alla pari di una pagina ASP: quando è richiesta dall’utente viene processata dal parser di linguaggio.

A differenza di ASP, però, dove la pagina è successivamente interpretata, con ASP.NET un compilatore si preoccupa della sua trasformazione in codice binario. Questa operazione è eseguita al primo accesso della pagina, oppure quando lo sviluppatore ne avrà alterato il contenuto. Tutti gli altri utenti della pagina ne riceveranno la versione già compilata, diminuendo di gran lunga i tempi di risposta, ma soprattutto il carico elaborativo. In caso di riavvio del server, la pagina non deve essere nuovamente compilata, giacché è memorizzata in una cache privata.

Il nuovo concetto di sessione

Le sessioni di ASP sono un comodo strumento per guidare l’utente tra più pagine di un sito e portare con sè le informazioni inserite. Si pensi ad un sito di commercio elettronico dove l’utente può in ogni momento verificare il contenuto del carrello e provvedere al pagamento. Sfortunatamente, le sessioni ASP richiedono l’utilizzo di cookie per il funzionamento. Non solo: le sessioni non possono essere utilizzate in realtà di tipo “Web Farm”, dove cioè più server si suddividono il carico elaborativo.

Con ASP.NET l’oggetto sessione è eseguito al di fuori del processo che gestisce l’applicazione Web: il risultato è che è possibile utilizzare le sessioni tra più server, e memorizzarne il contenuto in fonti di dati esterne, quali un file di testo oppure un server SQL. In caso di arresto critico del server, inoltre, la sessione può essere mantenuta e ristabilita. Un’ulteriore miglioria consente la fruizione delle sessioni anche a browser che non gestiscono i cookies, aggiungendo le informazioni come Querystring nell’URL.

Cache

Con ASP.NET è possibile costruire una cache per velocizzare la comunicazione con il browser e ridurre il consumo di risorse da parte del server. In base ad un discriminante la pagina è memorizzata in un’apposita cache e restituita al browser fino al verificarsi di una condizione che impone l’eliminazione e ricostruzione della cache. È una caratteristica molto versatile e potente. Una pagina può risiedere in memoria ad esempio fino allo scadere di un intervallo stabilito o fino a quando non cambia un file da cui dipende.

Debugging e tracing

Fino ad oggi mancavano delle tecniche efficienti per la correzione degli errori e l’analisi del codice, se non utilizzando le estensioni lato server rese disponibili da Visual Interdev. ASP.NET include un vero debugger (una versione più completa è distribuita con Visual Studio .NET) che è possibile configurare con i “breakpoint” e i “watches”, come se ci trovassimo in Visual Basic. Il file config.web (che si affianca a global.asax) può essere invece modificato per consentire il tracing del codice: informazioni rese disponibili sono tra le altre il dettaglio di richiesta della pagina, l’albero di generazione dei controlli, il contenuto delle variabili lato server e delle intestazioni HTTP.

Convivenza di ASP e ASP.NET

ASP e ASP.NET possono essere installati sullo stesso server senza interferire le une con le altre. Per ASP.NET l’estensione da utilizzare è solitamente .aspx (a differenza di .asp utilizzato per i documenti .ASP). E’ importante sottolineare che non è garantita la compatibilità 100% tra ASP e ASP.NET e che le due tecnologie non condividono lo spazio di memoria degli oggetti session e application: la comunicazione tra pagine ASP e ASP.NET sullo stesso server deve basarsi su componenti scritti ad hoc o sul passaggio di parametri “nascosti”.

Riscrivere il codice da zero

Se state valutando la possibilità di migrare un progetto ASP verso ASP.NET, dovete sapere che tutto il codice deve essere riscritto per poter sfruttare appieno le potenzialità di questa tecnologia. L’uso di controlli lato server e di form postback, unito alla possibilità di separare il codice dallo strato di presentazione, rende praticamente impossibile il riutilizzo del codice precedente.
Sarà improbabile che vengano realizzati in futuro dei tool di conversione automatici per la migrazione del codice (come invece è avvenuto con “l’upgrade wizard” di Visual Basic): le differenze sono di concetto più che di sintassi.

Conclusione

Molte le novità che distinguono ASP.NET dal predecessore, dal modello ad oggetti alle caratteristiche migliorate o completamente nuove.

Se siete incuriositi, siete pronti per il nostro corso online di ASP.NET!