ASP .NET 4.0 #2 Servizi "provider based"

Proseguendo nell’analisi delle nuove feature di ASP .NET 4.0 è evidente che l’architettura a providers, di cui tempo fa ho parlato in un articolo apparso su DotNetSide, è sempre più usata in modo intensivo per rendere quanto più modulare e personalizzabile l’application framework a disposizione.

Con la nuova versione di ASP .NET infatti questa architettura noto che sarà introdotta nei servizi di Output Caching, Browser Capabilities e Auto Start Application, almeno dalla documentazione in mio possesso.

Output Caching

Uno dei grossi limiti dell’ output caching delle precedenti versioni di ASP .NET è la limitatà flessibilità sul repository di memorizzazione dei dati in cache (output). Questi infatti potevano essere memorizzati solo nella memoria del server e da nessun altra parte. Come è facile intuire con la nuova versione è possibile scriversi un provider personalizzato per la memorizzazione dei dati e quindi utilizzare qualsivoglia repository a disposizione (es. disco locale, disco di rete, database, ecc)

Auto Start Application

Se si utilizza IIS 7.5 e Windows Server 2008 R2 insieme ad ASP .NET 4.0, è possibile far in modo che una applicazione si avvii in automatico ed esegua del codice di inizializzazione. Questo scenario si applica soprattutto a quelle applicazioni che necessitano di tempi lunghi per inizializzarsi, e quindi per evitare che questo overhead ricada totalmente sulla prima richiesta è possibile eseguire questo codice allo start-up automatico, ovvero senza che ci sia una richiesta di pagina esplicita. Questo codice può essere incapsulato in una classe provider, e quindi si possono avere n provider da utilizzare all’occorrenza in base alle specifiche esigenze.

Browser Capabilities

Questa funzionalità nelle precedenti versioni era fruibile solo mediante la modifica di files xml (.browser), a livello di macchina o di singola applicazione. Questi files xml non sono proprio il massimo per descrivere funzionalità come quelle del browser. Ora è possibile definire proprie funzionalità a livello di browser mediante l’uso di classi “provider based”

ASP .NET 4.0 #1 Nuova proprietà ViewStateMode

Per una applicazione ASP .NET soprattutto di livello enterprise la gestione del viewstate è sempre stato uno degli aspetti più delicati e, aggiungo io, più bistrattati in assoluto. Spesso e volentieri ho visto applicazioni di una certa complessità che ignorano completamente questo aspetto, che si traduce in pratica nell’utilizzo del valore di default della proprietà EnableViewState dei controlli di pagina (ovvero True), con conseguente saltataggio dei valori dello stato per tutti i controlli, a prescindere se questo salvataggio ha senso oppure no.

Anzi, spesso ho addirittura visto un utilizzo del ViewState a mò di Session, ovvero ho visto salvare informazioni aggiuntive rispetto allo stato dei controlli, e non parlo di tipi primitivi ma di veri e propri oggetti complessi, la cui serializzazione nel markup html provoca inevitabilmente un incremento notevole del peso della pagina web, con conseguenze facilmente immaginabili.

Con la prossima uscita della versione 4.0 di ASP .NET, lo sviluppatore avrà un controllo più fine sull’utilizzo del ViewState, soprattutto potrà impostare il valore di default desiderato in funzione della pagina che lo utilizza. Infatti, ogni server control (e quindi anche la classe Page) avrà a disposizione la proprietà ViewStateMode che potrà permettere ai controlli child situati all’interno di un contenitore (e quindi a tutti i controlli della pagina se guardiamo il livello più alto della gerarchia dei controlli), di ereditare la modalità di utilizzo dal rispettivo controllo container (valore Inherit), oppure di abilitare (Enabled) o disabilitare (valore Disabled) esplicitamente il Viewstate per un singolo controllo a prescindere dal valore impostato nel container.

Poichè il valore di default di questa nuova proprietà è Inherit, significa che a livello di pagina nessun controllo avrà il ViewState abilitato se non esplicitamente impostato dal programmatore.

Secondo me è un buon passo avanti verso la scrittura di applicazioni più efficienti.

Piccolo sfogo…

Una pensiero che spesso mi viene in mente guardando il codice sorgente è: ma perchè scrivere in 10 righe di codice quello che potrebbe essere scritto in una o due righe ?