Introduzione all'accesso ai dati mediante ADO.NET

Articolo
04/11/2008

Durante lo sviluppo delle applicazioni mediante ADO.NET, l'utilizzo dei dati comporterà diversi requisiti. In alcuni casi, potrebbe essere necessario visualizzare i dati in un form, in altri, potrebbe essere necessario escogitare un metodo per condividere le informazioni con un'altra società.

Indipendentemente dal modo in cui vengono utilizzati i dati, è importante comprendere alcuni concetti fondamentali relativi all'approccio ai dati in ADO.NET. Anche se una conoscenza dettagliata della gestione dei dati potrebbe non essere necessaria, in quanto non è detto che si verifichino casi in cui vada modificato direttamente un file XML contenente dati, è molto utile comprendere l'architettura dei dati in ADO.NET, riconscerne i principali componenti e il modo in cui si integrano tra loro.

In questa introduzione vengono fornite informazioni avanzate su questi importanti concetti. Verranno tuttavia deliberatamente ignorati molti dettagli, soprattutto quelli che riguardano i dataset, in quanto l'obiettivo principale di questa sezione consiste nel fornire semplicemente un'introduzione a concetti principali alla base dell'integrazione dei dati in ADO.NET.

Nota Quando viene distribuita un'applicazione che comprende i componenti di accesso ai dati di Visual Studio, è necessario assicurarsi che l'utente che installa l'applicazione disponga della versione 2.7 o successiva di MDAC (Microsoft Data Access Components). Per ulteriori informazioni, vedere Aggiunta di una condizione di avvio per Microsoft Data Access Components.

Assenza di dipendenza di ADO.NET da connessioni continuamente attive

Nelle tradizionali applicazioni client/server, i componenti stabiliscono una connessione a un database e la mantengono attiva durante l'esecuzione dell'applicazione. In molte applicazioni non è possibile utilizzare questo approccio per i seguenti motivi:

Le connessioni aperte ai database richiedono l'impiego di preziose risorse di sistema. Nella maggior parte dei casi, i database sono in grado di gestire solo un numero minimo di connessioni simultanee. L'overhead richiesto per la gestione di queste connessioni comporta una riduzione delle prestazioni globali delle applicazioni.
Analogamente, risulta estremamente difficile rendere scalabili le applicazioni che richiedono una connessione aperta al database. Un'applicazione di cui non è possibile realizzare una scalabilità completa potrebbe fornire un livello di prestazioni accettabile a quattro utenti ma non necessariamente a 100. Le applicazioni Web ASP.NET in particolare devono essere facilmente scalabili, in quanto il traffico su un sito Web può aumentare notevolmente in un periodo di tempo molto breve.
Nelle applicazioni Web ASP .NET i componenti sono disconnessi l'uno dall'altro. Il browser richiede una pagina al server. Al termine dell'elaborazione e dell'invio della pagina, il server non stabilisce altre connessioni con il browser fino alla richiesta successiva. In questi casi, il mantenimento di connessioni aperte a un database non è attuabile in quanto non esiste alcun modo per sapere se il consumer di dati, ovvero il client, richiederà ulteriori accessi ai dati.
Un modello basato su dati sempre connessi può rendere difficile e impraticabile lo scambio dei dati tra le applicazioni e i limiti organizzativi mediante un'architettura connessa. Se è necessario che due componenti condividano gli stessi dati, entrambi i componenti dovranno essere connessi o sarà necessario escogitare un metodo per consentire ai componenti di eseguire lo scambio dei dati.

Per tutte queste ragioni, la progettazione dell'accesso ai dati mediante ADO.NET si basa su un'architettura che utilizza solo sporadicamente le connessioni. Le applicazioni sono connesse al database solo il tempo necessario per recuperare o aggiornare i dati. Poiché il database non mantiene connessioni inattive per lungo tempo, è in grado di soddisfare le richieste di un maggior numero di utenti.

Interazioni del database realizzate mediante i comandi dei dati

Per eseguire delle operazioni in un database, è necessario eseguire istruzioni SQL o stored procedure che includono istruzioni SQL. L'utilizzo di istruzioni SQL o stored procedure consente di leggere e scrivere righe e di eseguire funzioni aggregate, quali l'aggiunta o il calcolo della media. Permette inoltre di creare o modificare tabelle o colonne per eseguire transazioni e così via.

In ADO.NET i comandi dei dati vengono utilizzati per creare il package di un'istruzione SQL o di una stored procedure. Se, ad esempio, si desidera leggere un insieme di righe dal database, sarà necessario creare un comando dei dati e configurarlo con il testo di un'istruzione SQL Select o con il nome di una stored procedure che recupera record.

Per richiamare le righe, è necessario effettuare le seguenti operazioni:

Aprire una connessione.
Chiamare un metodi di esecuzione del comando che, a sua volta:
1. Esegue l'istruzione SQL o la stored procedure a cui fa riferimento il comando.
2. Quindi chiude la connessione.
  
  La connessione resta aperta solo per il tempo necessario per l'esecuzione dell'istruzione o della stored procedure.

Quando si chiama un metodo di esecuzione di un comando, viene restituito un valore. I comandi che consentono di aggiornare il database restituiscono il numero di righe interessato. Altri tipi di comandi restituiscono invece un codice di errore. Se il comando esegue una query sul database con un'istruzione SELECT, potrà restituire un insieme di righe che sarà possibile recuperare mediante un lettore dati, il quale funge da cursore di sola lettura di tipo forward-only. Per ulteriori informazioni, vedere Recupero di dati mediante DataReader.

Nota sulla protezione Quando si utilizzano comandi dati con una proprietà CommandType impostata su Text, controllare attentamente le informazioni inviate da un client prima di passarle al database. Utenti malintenzionati potrebbero tentare di inviare istruzioni SQL modificate o aggiuntive con l'obiettivo di ottenere un accesso non autorizzato o di danneggiare il database. Prima di trasferire l'input di un utente in un database, si consiglia di verificare sempre che le informazioni siano valide. È opportuno utilizzare, quando possibile, query con parametri o stored procedure. Per ulteriori informazioni, vedere Attacchi tramite script.

Se è necessario eseguire più di un'operazione, ad esempio leggere e quindi aggiornare alcune righe, vengono utilizzati più comandi di dati, uno per ogni operazione. Ciascuna di esse viene eseguita separatamente. Per leggere, ad esempio, le righe, si apre la connessione, si leggono le righe, quindi si chiude la connessione. Quando si desidera aggiornare i dati, è necessario riaprire la connessione, effettuare l'aggiornamento e richiudere la connessione.

I comandi dei dati possono includere dei parametri, in particolare un insieme di oggetti parametro, che consentono di creare query con parametri come quelle che seguono:

Select * From customers Where (customer_id = @customerid)

È possibile quindi impostare i parametri in fase di esecuzione ed eseguire il comando per restituire o aggiornare i dati desiderati.

Inserimento nella cache di dati nei dataset

L'attività più comune di accesso ai dati consiste nel recupero di dati dal database per visualizzarli, elaborarli o inviarli a un altro componente. Molto spesso l'applicazione richiede l'elaborazione di un set di record anziché di un singolo record, come ad esempio un elenco di clienti o di ordini del giorno. Il set di record richiesto dall'applicazione spesso proviene da più tabelle, quali ad esempio i record relativi ai clienti e ai rispettivi ordini, quelli relativi a tutti gli autori di nome "Rossi" e ai rispettivi libri e altri insiemi di record correlati.

Una volta recuperati, questi record vengono utilizzati in genere nell'applicazione come gruppo. L'applicazione potrebbe consentire all'utente, ad esempio, di cercare tutti gli autori di nome "Rossi" e di esaminare i libri scritti da un Rossi, quindi di passare al Rossi successivo e così via.

In molti casi potrebbe risultare impraticabile accedere al database ogni volta che l'applicazione richiede l'elaborazione del record successivo. Questa operazione può vanificare gran parte del vantaggio di ridurre al minimo la necessità di connessioni aperte. Una delle soluzioni consiste quindi nell'archiviare temporaneamente i record recuperati dal database e utilizzare questo set di record temporaneo.

Per dataset si intende una cache di record recuperati da un'origine dati. Funge da archivio dati virtuale: include infatti una o più tabelle basate sulle tabelle presenti nel database effettivo e può includere informazioni sulle relazioni tra tali tabelle e i vincoli sui tipi di dati che le tabelle possono contenere.

I dati nel dataset rappresentano in genere una versione molto ridotta dei dati presenti nel database. È tuttavia possibile utilizzarli nello stesso modo in cui vengono utilizzati i dati reali, rimanendo disconnessi dal database, in modo da consentire al database di eseguire altre operazioni.

Naturalmente questo comporta la necessità di aggiornare spesso i dati presenti nel database, anche se tale operazione è meno frequente rispetto ai recuperi. Gli aggiornamento possono essere effettuati nel dataset e quindi scritti nel database sottostante.

Un aspetto importante da considerare è che il dataset è un contenitore di dati passivo. Per recuperare effettivamente i dati dal database e, facoltativamente, riscriverli, è necessario utilizzare gli adattatori dati. Un adattatore dati contiene uno o più comandi dei dati utilizzati per compilare una singola tabella nel dataset e per aggiornare la tabella corrispondente nel database. Contiene generalmente quattro comandi, rispettivamente per selezionare, inserire, aggiornare ed eliminare righe nel database. Pertanto, ogni volta che viene chiamato, il metodo Fill di un adattatore di dati potrebbe eseguire un'istruzione SQL quale SELECT au_id, au_lname, au_fname FROM authors.

Poiché costituisce in realtà una copia privata dei dati del database, il dataset non riflette necessariamente lo stato corrente del database. Se si desidera visualizzare le ultime modifiche apportate da altri utenti, sarà possibile aggiornare il dataset chiamando il metodo Fill appropriato.

Uno dei vantaggi dell'utilizzo dei dataset è rappresentato dal fatto che i componenti sono in grado di scambiarsi secondo le necessità. Un oggetto aziendale di livello intermedio, ad esempio, potrebbe creare e compilare un dataset, quindi inviarlo a un altro componente dell'applicazione per l'elaborazione. L'utilizzo di questa funzionalità non comporta la necessità per i componenti di interrogare singolarmente il database.

Indipendenza dei dataset dalle origini dati

Anche se un dataset funge da cache per i dati estratti da un database, non esiste alcuna relazione effettiva tra il dataset e il database. Il dataset è un contenitore che viene riempito dai comandi SQL o dalle stored procedure eseguite da un adattatore dati.

Poiché un dataset non è direttamente collegato a un'origine dati, rappresenta un ottimo punto di integrazione per i dati provenienti da più origini. I dati all'interno di un dataset, ad esempio, potrebbero provenire da database differenti o da un'origine diversa da un database, quale un foglio di calcolo. Alcuni dati in un dataset potrebbero arrivare in un flusso inviato da un altro componente. Una volta inseriti i dati in un dataset, sarà possibile utilizzarli mediante un modello di oggetti coerente, indipendentemente dalla relativa origine.

Persistenza dei dati in formato XML

È spesso necessario spostare i dati dall'archivio dati al dataset e dal dataset ai vari componenti. In ADO.NET il formato utilizzato per il trasferimento dei dati è XML. Analogamente, se i dati devono essere mantenuti, ad esempio in un file, verranno archiviati in formato XML. Se si dispone di un file XML, sarà possibile utilizzarlo come una qualsiasi origine dati e per la creazione di un dataset.

In effetti in ADO.NET il formato XML è un formato fondamentale per i dati. Le API dei dati ADO.NET creano automaticamente file o flussi XML in base alle informazioni presenti nel dataset e li inviano a un altro componente. È possibile che il secondo componente chiami funzioni API simili per la lettura del formato XML in un dataset. I dati non vengono memorizzati nel dataset in formato XML, ma in un formato più efficace: non è possibile ad esempio analizzare i dati in un dataset mediante un parser XML.

Se i protocolli di dati vengono basati su formati XML, sarà possibile usufruire di numerosi vantaggi:

XML è un formato standard. Questo implica che i componenti di dati dell'applicazione sono in grado di scambiare i dati con qualsiasi altro componente di una qualsiasi altra applicazione, purché tale componente riconosca il formato XML. La maggior parte delle applicazioni viene scritta per il riconoscimento del formato XML, che fornisce un livello di scambio delle informazioni tra applicazioni differenti che non ha precedenti.
XML è un formato basato su testo. La rappresentazione XML dei dati non si avvale di informazioni binarie, che ne consente l'invio mediante qualsiasi protocollo, ad esempio HTTP. La maggior parte dei firewall blocca le informazioni binarie, ma se le informazioni vengono formattate in XML, i componenti potranno continuare a scambiare facilmente i dati.

Nella maggior parte dei casi, non è necessario conoscere XML per poter utilizzare i dati in ADO.NET. In ADO.NET i dati vengono automaticamente convertiti in e da XML, in base alle necessità. L'utente interagisce con i dati utilizzando i metodi di programmazione ordinari.

Definizione delle strutture di dati negli schemi

Anche se per la lettura e la scrittura dei dati nel database e per l'utilizzo dei dataset non è necessario conoscere il formato XML, vi sono dei casi in cui è necessario utilizzare esclusivamente tale formato. Si tratta dei casi in cui non viene eseguito l'accesso ai dati, ma si lavora sulla progettazione dei dati. Più specificamente, in ADO.NET il formato XML viene utilizzato direttamente quando si opera con i metadati.

I dataset sono rappresentati in formato XML. La struttura, vale a dire l'identificazione delle tabelle, colonne, tipi di dati, vincoli e così via in essi contenuti, viene definita mediante uno schema XML basato sul linguaggio XSD (XML Schema Definition). È possibile caricare e serializzare la struttura del dataset come schema XSD, così come è possibile caricare e serializzare come XML i dati contenuti in un dataset.

Per la maggior parte delle operazioni eseguite con i dati in ADO.NET, non è necessario eseguire ricerche approfondite negli schemi. In genere, gli strumenti di Visual Studio .NET generano e aggiornano gli schemi, se necessario, in base alle operazioni eseguite nelle finestre di progettazione visive. Quando, ad esempio, si utilizzano gli strumenti per creare un dataset che rappresenti le tabelle nel database, in Visual Studio .NET viene generato uno schema XML che descrive la struttura del dataset. Lo schema XML viene quindi utilizzato per generare un dataset tipizzato, in cui gli elementi di dati (tabelle, colonne e così via) sono disponibili come membri di prima classe. Per ulteriori informazioni sui dataset tipizzati, vedere Introduzione ai dataset.

In alcuni casi, tuttavia, potrebbe essere necessario creare o modificare autonomamente gli schemi. Un esempio tipico è rappresentato dallo sviluppo di uno schema insieme a un partner o a un cliente. In tal caso, lo schema funge da contratto tra il programmatore e il partner in relazione alla forma dei dati basati su XML che verranno scambiati. In questa situazione, è spesso necessario associare gli elementi degli schemi alla struttura del database. Per ulteriori informazioni sulla progettazione di schemi, vedere Schemi XML e dati.

Componenti di ADO.NET

Nell'illustrazione che segue vengono raffigurati i componenti principali di un'applicazione ADO.NET.

Componenti di dati ADO.NET

Nella tabella riportata di seguito vengono riepilogati i componenti di dati ADO.NET precedentemente illustrati e forniti collegamenti a informazioni più dettagliate.

Componente o oggetto	Per ulteriori informazioni, vedere
Dataset	Introduzione ai dataset
Adattatore dati	Introduzione agli adattatori dati
Connessione dati	Introduzione agli strumenti di progettazione delle connessioni ADO.NET
Windows Form	Introduzione a Windows Form
Pagina Web Form	Introduzione alle pagine Web Form
BizTalk	Pagina Web BizTalk (https://www.microsoft.com/italy/biztalk)

Vedere anche

Share via