Tutorial ADO.NET & Oracle Parte 1

Le funzionalità fornite da ADO.NET sono molteplici, quali tra queste sono utili per le nostre esigenze? Questo tutorial cerca la risposta a questa domanda, indirizza l'apprendimento e l'utilizzo di ADO.NET secondo le esigenze tipiche di una Software Factory. Il tutorial perciò descrive l'architettura di ADO.NET, gli obiettivi e le finalità della tecnologia. Inoltre suggerisce le parti di maggiore utilità e le linee guida per l'utilizzo di ADO.NET e le specificità legate ad Oracle. Questa prima parte si concentra sulla comprensione della architettura di ADO.NET.

ADO.NET E ADO

ADO.NET presenta alcune similitudini con ADO e contemporaneamente presenta delle profonde differenze. Si potrebbe dire che la somiglianza maggiore sta nel nome, ossia nell'apparenza piuttosto che nella sostanza. Questa somiglianza è utile a chi conosce ADO per farsi guidare durante l'apprendimento di ADO.NET, ma può anche essere dannosa.

La maggiore differenza tra ADO e ADO.NET sta nel modello di accesso ai dati. Il modello di accesso ai dati di ADO è detto connesso, ossia presuppone che ogni applicazione disponga di una connessione al db costantemente aperta. Questo modello si basa sul presupposto che le risorse (memoria RAM, tempo CPU, ampiezza di banda) messe a disposizione dal db server siano praticamente illimitate rispetto al numero limitato degli utenti che vi accedono. Il modello di accesso ai dati di ADO.NET è disconnesso,ossia presuppone che una applicazione si connetta al db solo per il tempo strettamente necessario per recuperare dati (siano essi una o più selezioni) od inviare modifiche (siano cancellazioni, inserimenti e aggiornamenti, singoli o multipli). Durante l'esecuzione di una applicazione tipicamente la connessione verrà aperta per alcuni decimi di secondi e poi richiusa per un numero di volte pari ad alcune unità. Questo modello di accesso ai dati si basa sul presupposto che le risorse (memoria RAM, tempo CPU, ampiezza di banda) messe a disposizione dal db server siano limitate rispetto il numero degli utenti che vi accedono.

Il modello di ADO.NET bene si adatta alla caratteristica Stateless delle applicazioni Web ed al requisito di Scalabilità indispensabile per le moderne applicazioni (siano esse Client/Server, Distribuite o Web). Vien da se che in ADO.NET il concetto di Lock Pessimistico non esiste, con .NET è d'obbligo essere ottimisti.

Per un ulteriore confronto tra ADO e ADO.NET si veda:
Designing Distributed Applications with Visual Studio .NET: Data Access Technologies
Visual Basic and Visual C# Concepts: Comparison of ADO.NET and ADO
ADO.NET for the ADO Programmer

FUNZIONALITÀ E ARCHITETTURA DI ADO.NET

Rappresentazione dei dati in memoria

L'oggetto DataSet e gli oggetti ad esso collegati si trovano nel namespace System.Data . Attraverso questi oggetti è possibile la sola manipolazione dei dati in memoria, questa non ha alcun effetto diretto e automatico sulla fonte dati.

Accesso alla Fonte Dati

Il DataSet viene popolato con i dati provenienti dalla fonte dati che nel nostro caso è il database relazionale con estensioni ad oggetti Oracle9i. Quando si modificano i dati nel DataSet è necessario che le modifiche vengano inviate al database. Ciò che mette in collegamento il DataSet con il database è il .NET Data Provider mediante l'oggetto DataAdapter. Infatti l'oggetto DataAdapter contiene quattro oggetti Command, uno per ogni operazione (Select, Update, Delete e Insert). Ogni Command a sua volta ha il riferimento alla connessione rappresentata dall'oggetto Connection.Inoltre c'è l'oggetto DataReader simile ad un cursore ReadOnly ForwardOnly utilizzato dal DataAdapter per scorrere le righe restituite dal comando di Select e popolare una DataTable del DataSet.

Gli oggetti Connection, Command e DataReader possono essere usati anche singolarmente per esempio per eseguire una Stored Procedure, per scorrere efficientemente le righe di una tabella in sola lettura o per eseguire un comando SQL. I comandi di Select, Update, Delete e Insert del DataAdapter possono essere generati automaticamente tramite il Framework oppure possono essere valorizzati indicando esplicitamente comandi Sql o chiamate a Stored Procedure. Per ogni tipo di database esiste un diverso .NET Data Provider, ma tutti hanno in comune alcuni oggetti contenuti nel namespace System.Data.Common . Per accedere ad Oracle il .NET Data Provider da utilizzare fornit da Microsoft è il provider per OleDb che a sua volta si poggia sul Microsoft OleDb Provider for Oracle i cui oggetti sono contenuti nel namespace System.Data.OleDb , quindi vi è il Microsoft .NET Framework Data Provider for Oracle prodotto da Microsoft e l'Oracle Data Provider for .NET (ODP.NET) prodotto da Oracle.

DAI DATI IN MEMORIA AI CONTROLLI VISUALI: IL BINDING

La funzione di collegamento tra i dati in memoria mantenuti dal DataSet ed i controlli visuali avviene tramite l'oggetto DataView. Il collegamento, ossia il Binding, ha come soggetto la singola DataTable di un DataSet, tuttavia non è possibile eseguite il binding direttamente tra la DataTable ed il DataSource del controllo visuale: è necessario un DataView. Ogni DataTable ha un DataView predefinito che viene usato automaticamente quando si tenta di mettere in binding direttamente la DataTable.

Anche con il DataView le sorprese non mancano infatti il binding non è bidirezionale bensì avviene in una sola direzione: dalla DataTable al controllo visuale. Qualora il controllo visuale permetta di modificare i dati, queste modifiche non si rifletteranno automaticamente dal controllo visuale ai dati rappresentati in memoria, cioè nella DataTable e meno che meno si rifletteranno sulla fonte dati. Ciò è del tutto comprensibile se si pensa alla caratteristica stateless delle applicazioni Web e al modello di accesso ai dati disconnesso di ADO.NET; si avverte in questo caso l'armonia complessiva del disegno del .NET Framework. Sarà invece compito del programmatore implementare l'aggiornamento dei dati del DataSet a seguito delle modifiche effettuate dall'utente sui controlli visuali e sarà ancora compito del programmatore inviare le modifiche dal DataSet alla fonte dati.

I DOCUMENTI XML

ADO.NET è fortemente integrato alla tecnologia XML, non solo perché i dati nel DataSet sono internamente rappresentati in formato XML e le regole dello schema dei dati sono imposti con un XML-Schema, ma perché un documento XML può essere la fonte e l'origine dei dati elaborati tramite un DataSet. In ogni caso è bene tenere presente che per utilizzare proficuamente documenti XML con ADO.NET è quasi indispensabile conoscere lo standard XML-Schema (l'XML-Schema è per l'XML ciò che il DDL è per l'SQL) e avere a disposizione l'XSD dei documenti XML (quello che per l'SQL è lo schema del database) che si desidera impiegare.

Con ADO.NET è possibile utilizzare un qualunque documento XML (con relativo XML-Schema associato) come fonte dati. Questo permette di accedere in modalità relazionale ai dati contenuti del documento XML, perciò è possibile scorrere i dati, effettuare ordinamenti, effettuare ricerche e selezioni, effettuare il binding su controlli visuali e modificare i dati. Le modifiche potranno essere quindi riversate nel documento XML. Inoltre è possibile ottenere una rappresentazione in forma XML dei dati presenti nel DataSet da qualsiasi origine dati provengano, elaborare i dati in forma XML, quindi eseguire ricerche di tipo XPath, applicare trasformazioni XSL o XSLT, verificare la presenza di un nodo e modificare l'XML. Sarà quindi possibile aggiornare il DataSet dal documento XML così modificato.
Infine c'è la possibilità di mantenere sincronizzati automaticamente un documento XML e il relativo DataSet operando in consultazione o in modifica su entrambi. L'articolo XMLType versus Relational Schema espone dei criteri per scegliere tra le varie possibilità di operare sui dati.