Asp.Net Distributed Data Applications

Sono ben poche le applicazioni che non accedono a una fonte dati (sia essa un database o un file Xml) e sono ancora meno le applicazioni Asp.Net che non accedono ad una fonte dati.

Con questa premessa, Alex Homer e Dave Sussman, già autori del best seller Asp.Net: Guida per lo sviluppatore, hanno realizzato un intero testo dedicato alle applicazioni distribuite.

Per applicazione distribuita gli autori intendono un programma (o meglio, un progetto) che è funzionalmente e/o geograficamente suddiviso in componenti logiche che comunicano tra di loro.

Con questa definizione sono in realtà possibili diverse applicazioni reali, ognuna delle quali presentate nel testo.

E’ ad esempio possibile impiegare un server che si occupa dell’accesso ai dati e della logica di business e un client contenente la sola interfaccia al programma.

All’estremo opposto ci sono invece le applicazioni n-tier in cui la logica di business è suddivisa tra il data tier, il middle tier e il presentation tier.

La scelta di un modello piuttosto di un altro si basa su diversi fattori, primo fra tutti le costrizioni date dal tipo di piattaforma e di client utilizzati.

Gli autori esplorano i pregi e i difetti di ogni soluzione e passano progressivamente con i loro esempi dalla soluzione 3 tier “classica”, a quella n-tier più realistica.

Sono proprio questi casi semplici, ma completi e le diverse soluzioni proposte che rendono il libro interessante. Nel corso dei capitoli si passa infatti dallo sviluppare prima per client dalle caratteristiche limitate, come browser datati o cellulari, poi per browser in grado di interpretare correttamente Xml e Xsl ed infine per client in cui è installato il .Net Framework.

Per prima cosa ci si preoccupa di come visualizzare le pagine ed i programmi sui diversi client, successivamente ci si passano in rassegna le tecniche più efficaci per l’aggiornamento dei dati.

Gli autori pretendono che il lettore non sia del tutto a digiuno di Asp.Net. Ciononostante, argomenti quali l’utilizzo delle sorgenti dati e di Xml in Asp.Net sono approfonditamente introdotti nei primi capitoli del testo.

Capitoli gratuiti

Grazie ad un accordo con la casa editrice, i nostri lettori hanno la possibilità di leggere due capitoli del manuale:

Informazioni

Asp.Net Distributed Data Applications ¤ di Alex Homer e Dave Sussman ¤ lingua inglese ¤ pagine 650 ¤ prezzo 49.99 dollari ¤ edito da Wrox

Sito del manuale [nuova finestra] (scheda, errata, capitolo gratuito)

Real World Asp.Net: Building a Content Management System

Abbiamo già avuto modo di occuparci di un manuale riguardante i Content Management Systems, il cui approccio è poco tecnico e rivolto soprattutto ai project manager.

Questo manuale, invece, utilizza la tecnologia Asp.Net per realizzare un completo sistema per la gestione dei contenuti, che è anche disponibile online.

E’ quindi un testo indicato agli sviluppatori che vogliono analizzare un caso reale per utilizzarlo come base per il proprio sistema.

In effetti l’esempio, anche se completo, non può essere paragonato ad un Cms come quelli disponibili in commercio. Fa bene l’autore a lamentarsi per il costo esagerato di questi sistemi, ma il suo prodotto ha comunque valenza esclusivamente didattica.

Il testo comincia con una presentazioni delle caratteristiche e dei componenti di un Cms, per poi affrontare Asp.Net introducendo le componenti principali della piattaforma. Solo nell’ultima parte è analizzato il progetto, chiamato Cms.Net.

Ed è in effetti questo il limite del testo: sarebbe stato meglio dare per scontata almeno l’introduzione ad Asp.Net e presentare un esempio più completo.

La presentazione dei Cms è comunque realizzata molto bene e vi potrà tornare utile qualunque implementazione decidiate di realizzare.

Pro

  • Buona l’introduzione teorica ai Cms

Contro

  • Sarebbe stato meglio dare per acquisita la tecnologia Asp.Net e concentrarsi da subito sul progetto Cms.Net

Informazioni

Real World Asp.Net: Bulding a Content Management System ¤ di Stephen R.G. Fraser ¤ lingua inglese ¤ pagine 500 ¤ prezzo 49.95 dollari ¤ edito da Apress

Sito del manuale [nuova finestra] (scheda, errata, capitolo gratuito)

ASP.NET: Politiche di Caching

Corso ASP.NET: tredicesima puntata

Esempio funzionante | Sorgente | Scarica il sorgente (zip)

La ripetitività e l’intensità nell’uso delle applicazioni Internet fa sì che sia teoricamente possibile prevedere dei meccanismi di salvataggio e recupero di pagine od oggetti dalla memoria, ai fini di aumentare le prestazioni.

Per questo motivo, a differenza di Asp, Asp .Net rende disponibili delle sofisticate tecniche di caching che, adottate correttamente, consentono allo sviluppatore di ridurre l’uso intensivo di alcune risorse, come la Cpu e le connessioni a database.

Con Asp.Net è possibile utilizzare due tipi di caching:

  • Output caching – utilizzato per memorizzare pagine o porzioni di pagine in memoria, così da ridurre l’esecuzione del codice che le compongono
  • Data caching – utilizzato per memorizzare qualunque tipo di oggetto, soprattutto Dataset o risultati di trasformazioni Xml

La cache viene normalmente riempita al primo caricamento della pagina o dell’oggetto da parte dell’utente. Le successive richieste vengono invece servite impiegando la copia compilata e precedentemente memorizzata nella cache, evitando la ri-esecuzione del codice.

Con Asp.Net è anche possibile definire dei discriminanti che possono invalidare la copia cache non valida e richiedere quindi la sua ricostruzione. Tipici eventi sono rappresentati dallo scadere di un intervallo di tempo o la modifica di file di dipendenza.

Output caching

L’output caching consente di ridurre il carico applicativo perché, dopo la prima richiesta della pagina, questa viene memorizzata nella cache.

Questa funzionalità si ottiene specificando in testa alla pagina qualcosa del tipo:

<%@ OutputCache Duration=”30″ VaryByParam=”None” %>

L’esempio sopra riportato mantiene la pagina nella cache per 30 minuti, allo scadere dei quali una nuova versione viene compilata e memorizzata.

I discriminanti con i quali è possibile confrontare la pagina sono:

  • Duration – la durata (in minuti) della pagina nella cache
  • VaryByParam – i parametri che provengono da una QueryString (get) o dal post di un form
  • VaryByHeader – l’header Http associato ad una pagina
  • VaryByCustom – un parametro configurabile, normalmente il tipo di browser utilizzato

Supponiamo ad esempio di avere una pagina che riceve come parametro l’anno di pubblicazione di un libro. E’ possibile inserire nella cache una versione di pagina per ogni anno di ricerca. La direttiva assume in questo caso una forma del tipo:

<%@ OutputCache Duration=”30″ VaryByParam=”AnnoPubblicazione” %>

Data caching

Il data caching consente un controllo più raffinato, perché opera a livello di oggetti invece che a livello di pagina.

Per inserire e rimuovere oggetti dalla cache è in questo caso possibile utilizzare la classe Cache, ospitata dal namespace System.Web.Caching.

Nel caso più semplice, per inserire un oggetto nella cache si usa una struttura del tipo:

Cache(“chiave”) = valore

Per rimuovere un elemento, si usa invece:

Cache.Remove(“chiave”)

Un elemento può essere inserito nella cache anche con il metodo Insert, tramite il quale è possibile specificare i discriminanti che portano alla “scadenza” dell’oggetto.

C’è ad esempio la possibilità di legare la cache ad un file presente sul server o ad un altro oggetto presente nella cache, e di invalidarla al modificarsi del documento. Per farlo si utilizza la classe CacheDependency.

Nell’esempio che segue viene realizzata una trasformazione tra un documento Xml e un documento Xsl. Il risultato viene memorizzato in cache e lì rimane fino a quando il file Xml non subisce un aggiornamento.

La prima volta che viene caricata la pagina, viene eseguita la trasformazione e l’oggetto è salvato in cache:

Tabella di libri con la scritta: Elemento non presente in cache... lo carico

Successivamente viene riportata una scritta che indica come il caricamento venga eseguito dalla cache:

Tabella di libri con la scritta: Elemento già presente in cache

La funzione PopolaCache (riportata qui sotto), si preoccupa di trasformare il documento Xml con il foglio Xslt e di memorizzare il risultato nella cache, con il metodo Insert. Viene utilizzata la classe CacheDependency per creare una dipendenza tra l’elemento in cache e il file fisico del documento Xml.

 42 Public Sub PopolaCache(strFileXml As String)
 43 
 44  Dim objXml As New XmlDocument
 45 
 46  objXml.Load(Server.MapPath(strFileXml))
 47 
 48  Dim objCDep as new CacheDependency(Server.MapPath(strFileXml))
 49 
 50  Cache.Insert(strFileXml, objXml, objCDep)

Se la cache è vuota viene richiamata la funzione PopolaCache:

 26   If (IsNothing(Cache("xml.xml"))) Then
 27     risposta.innerText = "Elemento non presente in cache…lo carico"
 28     PopolaCache("xml.xml")
 29   Else
 30     risposta.innerText = "Elemento già presente in cache"
 31   End If

In entrambi i casi, l’oggetto viene caricato prelevandolo dalla cache:

 33   objXsl.Load(Server.MapPath("xsl.xsl"))
 34 
 35   objXml = CType(Cache("xml.xml"), XmlDocument)
 36 
 37   libri.Document = objXml
 38   libri.Transform = objXsl

Se a questo punto modifichiamo (ad esempio con un editor di testo) il documento Xml, Asp.Net esegue nuovamente la trasformazione eliminando il precedente contenuto dalla cache.

Session, Application e Cache

Nel memorizzare un oggetto, lo sviluppatore ha a disposizione 3 strade: utilizzare le sessioni, l’oggetto application o la cache

In linea generale, ecco le situazioni in cui usarle:

  • Le sessioni dovrebbero essere impiegate quando è necessario registrare l’attività dell’utente nel sito, come ad esempio un carrello di commercio elettronico
  • L’oggetto application va utilizzato per memorizzare informazioni puntuali e comuni a tutto il progetto, come ad esempio la stringa di connessione ad un database. E’ un oggetto che andrebbe usato con parsimonia
  • La cache si presta ad ospitare pagine od oggetti di cui è possibile prevedere l’obsolescenza (al passare del tempo e al verificarsi di una certa condizione). Va impiegata nelle situazioni in cui c’è un effettivo guadagno in termini prestazionali o di risparmio delle risorse.