Nel precedente articolo ci siamo soffermati sui primi 5 punti che rendono ASP.NET più conveniente, per uno sviluppatore, rispetto a Classic ASP, analizzando le differenze, spesso soprattutto concettuali, che caratterizzano le due tecnologie.

Per tenere fede al titolo di questa serie di articoli, dobbiamo ancora analizzarne un po', che a prima vista potrebbero sembrare dedicate a progetti più avanzati, ma che in realtà riflettono spesso le necessità di applicazioni anche poco sofisticate, perché riguardano soprattutto aree come la sicurezza, la scalabilità e la flessibilità di sviluppo.

Caching: preservare le risorse

Anche in questo caso siamo di fronte ad una funzionalità che in Classic ASP non è presente e che viene surrogata attraverso l'utilizzo di Application o Session, a seconda delle necessità.

La gestione della cache è una delle funzionalità più interessanti di ASP.NET, perché consente di mantenere in memoria un oggetto (ed essendo la pagina un oggetto, questa funzionalità è disponibile anche per memorizzare direttamente l'HTML prodotto dalla relativa esecuzione) senza dover ogni volta rielaborarne l'estrazione. Badate bene che per memoria si intende, ovviamente, quella del server ed il vantaggio principale dell'utilizzo di queste tecniche è quello che si preserva del tutto il consumo di risorse, necessità essenziale quando il carico di un'applicazione si fa sentire, oppure quando il frutto di un'elaborazione è particolarmente oneroso.

Più in generale questo approccio si applica in tutti quei casi in cui si può applicare questa semplice regola: risparmiare risorse, evitando continue chiamate, ad esempio, ad un database.

Tutto questo potrebbe sembrare già disponibile con ASP, attraverso l'utilizzo di Session o Application (che sono ancora supportati con ASP.NET e funzionano all'incirca nello stesso identico modo), ma, dando un'occhiata più da vicino, ci si accorge che il vero vantaggio dell'infrastruttura di Caching di ASP.NET sta nella sua versatilità.

I dati in Cache, infatti, possono essere rimossi in automatico attraverso scadenze temporali oppure con dipendenze da file, altri oggetti o SQL Server.

Questo vuol dire che si può tenere in Cache un dato per 10 minuti e fare in modo che venga in automatico mantenuto aggiornato al relativo scaricamento dalla memoria, scrivendo qualcosa come questo pezzo di codice:

Dim o as Object = Cache("miooggetto")
 
' carico il dato in cache
If o is Nothing then
  Cache.Insert("miooggetto", "miovalore", nothing, _
  DateTime.Now.AddMinutes(10), TimeSpan.Zero)
End If

L'ambito in cui l'utilizzo della cache dà il meglio di sé è quello relativo all'estrazione di dati da un database, al fine di evitare di richiedere ogni volta dati che con buona probabilità vengono aggiornati solo poche volte al giorno.

Come con tutte le cose, comunque, è una funzionalità di cui non bisogna abusare, pena un consumo anche sostanzioso della memoria del server ed un effetto totalmente contrario rispetto a quello per cui invece l'utilizzo della cache si rivela vincente.

Per approfondire l'argomento è consigliabile dare un'occhiata a questo articolo.

Estendibilità: COM e XCopy deployment

Dove davvero non c'è storia è quando si paragona il deployment (e quindi di fatto, l'estendibilità con componenti esterni). Classic ASP favorisce lo spaghetti code (cioè, codice HTML misto a codice server side) anche perché l'unico modo per componentizzare un'applicazione è sfruttare gli oggetti COM.

Chiunque abbia mai avuto a che fare con COM, anche come utente, sa di sicuro quali sono i problemi: versioning, registrazione dei componenti. In pratica, l'impossibilità di tenere versioni diverse di uno stesso oggetto sullo stesso computer e la necessità di fermare il processo che tiene in uso un oggetto ad ogni aggiornamento.

Questo ha portato negli anni ad utilizzare ASP come un contenitore di codice VBS, mentre in realtà nei piani (almeno iniziali) di Microsoft c'era l'idea di farne più che altro un collante per oggetti COM.

All'atto pratico ASP/COM sono stati utilizzati in questo modo solo in scenari enterprise, laddove, cioè, è assolutamente necessario componentizzare ed avere un disegno dell'applicazione, anche a costo di essere meno flessibili.

ASP.NET, grazie anche e soprattutto al modello del .NET Framework su cui si poggia, taglia alla base questi problemi, grazie all'utilizzo di un meccanismo che fa sì che ogni applicazione possa avere i propri oggetti personalizzati, senza condividerli per forza con le altre.

Inoltre gli assembly, ovvero il corrispondente delle DLL in COM, hanno al loro interno un cosiddetto manifest, che serve in pratica ad istruire l'ambiente su quali sono le funzionalità contenute sotto forma di classi all'interno del file.

Questo rende possibile il cosiddetto XCopy deployment, ovvero la messa in produzione di applicazioni semplicemente attraverso la copia di tutti i file. Per convenzione, poi, ASP.NET cerca eventuali assembly aggiuntivi all'interno della directory /bin/ posta sotto la root dell'applicazione, per cui basta copiarli all'interno di questo percorso.

In un modello simile creare funzionalità aggiuntive incapsulate in oggetti è semplicissimo, anche grazie al fatto che Visual Studio 2005 ne facilita lo sviluppo, anche con le versioni Express.

Il poter componentizzare maggiormente un'applicazione porta vantaggi indiscutibili, derivanti anche dal fatto che i linguaggi utilizzati sono orientati agli oggetti, quindi hanno caratteristiche come ereditarietà, polimorfismo ed incapsulamento che rendono possibile estendere all'infinito le funzionalità grazie alla possibilità di derivare oggetti ed arricchirli.

La creazione di classi è tutt'altro che semplice per chi non l'ha mai fatto, ma i vantaggi di poter sfruttare un insieme di oggetti creati da terzi senza necessità di registrarli, ma semplicemente copiandoli, è comunque qualcosa che dovrebbe farvi capire la portata di qualcosa del genere. Potete comunque farvi un'idea attraverso la consultazione di questo articolo.