Praticamente tutte le applicazioni hanno la necessità di interrogare o aggiornare dati persistenti memorizzati in file piatti, database relazionali o altri tipi di supporto di memorizzazione. Per ovviare a tale necessità, il .NET Framework include ADO.NET, un sottosistema per l'accesso ai dati ottimizzato per ambienti N-tier ed interoperabile con l'XML ed i documenti XML. ADO.NET è stato progettato per gli ambienti debolmente accoppiati. Come il nome stesso implica, ADO.NET rappresenta l'evoluzione di ADO (ActiveX Data Objects).

ADO.NET è stato pensato per fornire servizi per l'accesso ai dati ad applicazioni scalabili e servizi basati sul Web. ADO.NET mette a disposizione API ad elevate prestazioni per modelli di dati sia connessi sia disconnessi particolarmente adatti alla restituzione di dati alle applicazioni Web.

Quando si sviluppano applicazioni, i dati vengono utilizzati nei modi più disparati. In alcuni casi, ad esempio, l'obiettivo potrebbe essere quello di mostrare semplicemente i dati in una form. In altre situazioni, potrebbe essere necessario condividere le informazioni con altre aziende.

Architettura dati disconnessa

Nelle tradizionali applicazioni two-tier, le componenti stabiliscono una connessione ad un database e la mantengono aperta per l'intera durata dell'esecuzione. Per svariati motivi, un tale tipo di approccio risulta decisamente poco pratico in numerose applicazioni:

• Aprire connessioni a database consuma risorse preziose sul server. Il sovraccarico necessario al mantenimento di tali connessioni influisce negativamente sulle prestazioni dell'applicazione.
• Le applicazioni che richiedono una connessione aperta a database risultano estremamente difficili da scalare. Non è detto che un'applicazione che funziona in modo accettabile con quattro utenti faccia altrettanto se gli utenti raggiungono il centinaio. Le applicazioni Web, in particolare, hanno bisogno di essere facilmente scalabili, dal momento che il traffico su un sito Web può aumentare considerevolmente in pochissimo tempo.
• Nelle applicazioni Web, le componenti sono di per sé stesse disconnesse le une dalle altre. Il browser richiede una pagina al server; una volta che questo ha terminato l'elaborazione ed ha inviato la pagina, non risulta più connesso al browser fino alla successiva richiesta. In queste circostanze, non ha senso mantenere aperta la connessione al database, dal momento che non c'è modo di sapere se il client chiederà o meno di accedere nuovamente ai dati.
• Un modello basato su dati connessi può complicare la condivisione dei dati tra componenti specialmente se queste appartengono ad applicazioni differenti. Se due componenti devono condividere gli stessi dati, è necessario che siano connesse, oppure occorre individuare un metodo che consenta di passare i dati dall'una all'altra.

Per tutti questi motivi, l'accesso ai dati in ADO.NET è stato progettato sulla base di un'architettura disconnessa. Le applicazioni rimangono connesse al database solamente per il tempo necessario ad estrarre o aggiornare i dati. Poiché il database non risulta legato a connessioni potenzialmente inattive, può essere utilizzato da moltissimi utenti.

Memorizzazione dei dati in dataset

Da sempre le più comuni operazioni sui dati consistono nell'estrarli da un database, nel visualizzarli, elaborarli o inviarli ad un'altra componente. Molto spesso, l'applicazione necessita di elaborare non un solo record, ma un insieme di record; ad esempio, l'elenco dei clienti che hanno effettuato ordini in giornata. Spesso l'insieme di record richiesto dall'applicazione deriva da più tabelle: i clienti e tutti i loro ordini, tutti gli autori di nome "Smith" ed i relativi libri, ad altri insiemi simili di record correlati.

Una volta estratti i record, generalmente l'applicazione li gestisce come gruppo. Ad esempio, l'applicazione potrebbe consentire all'utente di navigare tra tutti gli autori di nome "Smith", esaminare i libri di un particolare autore, passare al successivo e via dicendo.

In un modello di dati disconnesso, non è pratico accedere al database ogni volta che l'applicazione deve elaborare il record successivo. (Così facendo si vanifica il vantaggio di lavorare con i dati disconnessi). La soluzione, pertanto, consiste nel memorizzare temporaneamente i record estratti dal database e lavorare su questo insieme temporaneo.

Un dataset non è altro che un insieme di record estratti da un database e memorizzati in una cache local, che e si comporta come store di dati virtuale - include una o più tabelle che si basano sulle quelle di uno o più database e può includere informazioni sulle relazioni tra le tabelle ed i vincoli sui dati in esse contenuti.

I dati nel dataset rappresentano generalmente una versione molto ridotta di ciò che è contenuto nel database. Tuttavia, è possibile utilizzarli come se fossero dati reali. Durante questa fase, si rimane disconnessi dal database, che a sua volta è libero di effettuare altre operazioni.

Naturalmente, è necessario aggiornare spesso i dati nel database (sebbene non con la stessa frequenza con cui è necessario estrarli). A questo proposito è possibile effettuare le operazioni di aggiornamento sul dataset, e queste verranno propagate al database sottostante.

Un punto importante è che il dataset è un contenitore di dati passivo. Per estrarre effetivamente i dati da un database e (eventualmente) scriverli, occorre utilizzare un data adapter. Un data adapter contiene le istruzioni che consentono di popolare una singola tabella del dataset ed aggiornare la corrispondente tabella del database. Le istruzioni sono metodi che incapsulano codice SQL, come il riferimento ad una stored procedure. Pertanto, il metodo Fill può invocare un'istruzione SQL quale SELECT au_id, au_lname, au_fname FROM authors che viene eseguita ogni volta che il metodo viene chiamato.

Dati resi persistenti come XML

I dati devono essere spostati da un data store al dataset, e da qui a varie componenti. In ADO.NET, il formato predefinito per il remoting dei dati è l'XML.

Quando è necessario rendere persistenti i dati al di fuori del database (ad esempio, all'interno di un file), li si memorizza come XML. Se si ha a disposizione un file XML, è possibile utilizzarlo come sorgente dati e per creare un dataset.

Infatti, in ADO.NET, l'XML rappresenta il formato fondamentale per la condivisione dei dati. Quando si condividono i dati, le API di ADO.NET creano automaticamente file o stream XML sulla base delle informazioni presenti nel dataset e li inviano ad un'altra componente. Questa, a sua volta, può invocare API simili per restituire l'XML ad un dataset.

La scelta su XML è caduta per diversi motivi, ad esempio:

• L'XML è un formato standard per le aziende. Ciò significa che le componenti possono scambiare i dati con altre componenti in ogni altra applicazione, sempre che questa supporti l'XML. Molte applicazioni progettate per accettare ed interpretare XML, il che fornisce un livello di scambio elevato tra applicazioni diverse.
• L'XML utilizza un formato testuale. Poiché l'XML non rappresenta i dati in formato binario, è possibile utilizzare qualsiasi protocollo, come ad esempio l'HTTP, per inviare informazioni in formato XML. Dal momento che la maggior parte dei firewall blocca i dati in formato binario, è possibile far sì che le componenti continuino a scambiarsi informazioni formattandole in XML
• Interoperabilità. ADO.NET consente di creare con facilità documenti XML personalizzati che utilizzano gli schemi XSD. Gli schemi XSD risultanti generano l'XML per utilizzi specifici.

 

Fonti:

.NET Framework SDK Evaluation Guide

.::^top^::.