Struttura del Modello ADO.NET

Il progetto ADO è stato introdotto già in COM, successivamente è stato sviluppato nuovamente per la piattaforma .NET, mantenendo però l’utilizzo di ADO con ADO.NET attraverso l’uso dei recordset e grazie a degli adattatori inseriti nel nuovo modello. Perché, quindi, Microsoft ha pensato di realizzare un nuovo modello di classi per l’accesso ai dati? Con l’ampliarsi degli scenari aziendali, reti private che si interconnettono attraverso reti pubbliche, le applicazioni client/server gestionali devono adeguarsi a questa rivoluzione. L’impegno delle aziende e dei produttori di software verso l’XML ed i Web Services sono un segnale di questa necessità di integrazione e del forte impegno di semplificare le applicazioni distribuite su larga scala. In questo scenario i programmi hanno bisogno di gestire i dati in modo indipendente dalla fonte di provenienza e XML è il collante che è stato trovato.
Anche ADO.NET soffre però di problemi, come ad esempio la gestione dei dati durante una possibile disconnessione dalla fonte dati remota, in questo caso ADO utilizza il concetto di recordset, ossia prelevare i dati da remoto, inserirli in un archivio XML locale, lavorare su questo e poi inviare nuovamente le modifiche o le aggiunte alla fonte dati remota.
Le classi di ADO.NET sono suddivise in namespace, in particolare in questo caso System.Data. All’interno di questo namespace troviamo la classe base per la gestione dei dati disconnessi, DataSet che  ci permette di gestire in memoria una cache disconnessa indipendente dalla fonte dati, nella quale possiamo inserire viste provenienti da fonti diverse che in memoria diventano tabelle e relazioni basate su chiavi esterne tra queste. I dati in un DataSet sono editabili e gestibili sia attraverso una vista relazionale, sia attraverso una vista XML completamente sincronizzate e provenienti da specifici database, attraverso i cosidetti managed provider. Questi sono ottimizzati per una specifica fonte dati, ma esiste un managed provider che si appoggia su OleDb e che permette di utilizzare le classi provider oggi esistenti e di esporle al nuovo modello di accesso ai dati, questo namespace è il System.Data.OleDb. Esistono tuttavia dei managed provider ottimizzati per una specifica fonte dati, come ad esempio Microsoft SQL Server che è contenuto nel namespace System.Data.SqlClient. Si possono sviluppare tutti i provider che vogliamo e quindi utilizzare varie base dati con lo stesso applicativo, basta cambiare la stringa di connessione al database e poco altro. In futuro ho intenzione di mostrare, qui su questo blog, come creare un provider di dati per MySQL, scritto in ATL.
Oltre alle classi necessarie a permettere la gestione di connessioni ed il caricamento di dataset e l’esecuzione di comandi SQL, nei managed provider troviamo anche la classe DataReader che ci consente di gestire il cursore lato server di sola lettura a scorrimento in avanti ( forward ) per la rapida lettura di dati restituiti dall’esecuzione di una query. In un dataset, oltre ai dati provenienti da un provider, possiamo anche caricare le informazioni direttamente da stream o file XML e questo è molto importante per poter inviare il contenuto su altre piattaforme anche eterogenee tra loro.
In un prossimo articolo spiegheremo la classe DataSet e ne vedremo l’uso pratico nel caricamento di un file XML.