Tutorial ADO.NET & Oracle

Parte 2: Scelta del Provider per Oracle



P   a   r   t   e   1          -          P   a   r   t   e       2          -          P   a   r   t   e       3          -          P   a   r   t   e       4



INTRODUZIONE

Le funzionalità fornite da ADO.NET sono molteplici, quali tra queste sono utili per le nostre esigenze? Questo tutorial cerca la risposta a tale 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 seconda parte si concentra sul .NET Data Provider per accedere ad Oracle.


SCELTA DEL PROVIDER PER ORACLE

ADO.NET fa uso di un nuovo tipo di provider per comunicare con la fonte dati. Questa nuova tecnologia viene genericamente chiamata .NET Data Provider e sostituisce la tecnologia OleDb ed ODBC. Ogni fonte dati e quindi ogni marca di database richiede un suo specifico .NET Data Provider che è necessario ad ADO.NET per comunicare con la fonte dati.

.NET Data Provider


Il .NET Data Provider disponibili  per Oracle sono tre:
  1. Microsoft OLE DB .NET Data Provider  + Microsoft OleDb Provider for Oracle
  2. Microsoft .NET Framework Data Provider for Oracle
  3. Oracle Data Provider for .NET (ODP.NET)
Il Microsoft OLE DB .NET Data Provider permette di accedere alle funzioni di un qualsiasi OleDb provider e quindi può essere utilizzato per sfruttare il provider per Oracle "Microsoft OleDb Provider for Oracle". Tuttavia questa è una soluzione transitoria in attesa della disponibilità di .NET Data Provider nativi per Oracle. La provvisorieta di  questa soluzione è marcata dal fatto che l'OleDb provider per Oracle prodotto da Microsoft non è certificato per Oracle9i  e MS stessa dichiara che tale OleDb provider non verrà reso compatibile alle successive versioni di Oracle.

Da una valutazione comparativa dei due rimanenti provider  non emergono sostanziali differenze tecniche tali da far propendere sistematicamente per uno o per l'altro. In taluni aspetti il provider per Oracle realizzato dalla Microsoft è lievemente superiore a quello prodotto da Oracle, in altri aspetti quello prodotto da Oracle risulta lievemente superiore a quello prodotto da Microsoft.

Vista la lieve differenza tecnica tra i due provider, un fattore non tecnico che può rivelarsi determinante per la scelta del provider è il contratto di assistenza che la Software Factory ha con il supporto Oracle e/o con quello Microsoft, la fiducia e la qualità del rapporto con i rispettivi supporti oltre che i costi per le singole chiamate aperte.

Complessivamente e genericamente il provider prodotto dalla Oracle risulta tendenzialmente migliore ma soprattutto appare una volontà da parte di Oracle di investire ora e nel futuro nel suo provider per .NET in termini di qualità, di supporto alle specificità del data base Oracle, di produzione di documentazione, esempi e gestione di Forum per aiutare, consigliare ed indirizzare l'utilizzo del provider.

Ecco in sintesi alcuni dati tecnici a favore del Oracle Data Provider for .NET (ODP.NET):
Ecco in sintesi alcuni dati tecnici a favore del Microsoft .NET Framework Data Provider for Oracle;

Se gli elementi sopra esposti non fossero sufficienti ad indurre una scelta nel caso specifico o se comunque ci fosse ancora il dubbio, suggerisco di usare il provider della Oracle a chi intende fare un uso esteso del db Oracle e delle sue funzionalità o ha comunque confidenza col db Oracle mentre suggerisco di usare il provider della Microsoft a chi non ha confidenza del db Oracle e intende fare un uso limitato del db Oracle.


INDIPENDENZA DAL PROVIDER?

Tutti i .NET Data Provider per ADO.NET sono tenuti ad implementare una serie di interfacce standard definite nel namespace System.Data , queste interfacce sono:
nonostante ciò ad ogni provider è concesso fornire funzionalità specifiche della fonte dati con metodi ed oggetti specifici, non compresi tra queste interfacce; per esempio tipi dato specifici di un db, modalità di ottenere un cursore aperto come valore di ritorno da una Stored Procedure, livelli di isolamento disponibili per una transazione, disponibilità di transazioni nidificate o segmentate, eccetera.
Questa novità rappresenta la presa di coscienza dopo le esperienze con ODBC ed OleDb che il vincolo per un provider di rispetto di interfacce standard è di poco uso o addirittura di intralcio se la semantica di diversi provider (ossia i servizi che diversi provider foriscono) sono non equivalenti. Quindi l'illusione che c'è stata ai tempi di ODBC ed OleDb di poter sostituire semplicemente il provider senza bisogno di intervenire significativamente nel codice della applicazione è tramontata.
A prova di ciò, anche la semplice sostituzione tra due provider tra loro simili come il "Microsoft .NET Framework Data Provider for Oracle" ed "Oracle Data Provider for .NET (ODP.NET)"  in una applicazione che si attiene strettamente all'uso delle sole interfacce standard, rinunciando con ovvio danno alle molte estensioni dei singoli provider, richiede ad esempio la modifica delle stringhe di connessione nonché di tutte le stringhe SQL che contengono parametri; fatto ciò  non è garantito che tutti i metodi delle interfacce debbano essere implementati da entrambi i provider in quanto ad ogni provider è lasciata la libertà di sollevare l'eccezione NotImplementedException oppure NotSupportedException o semplicemente di non fare nulla.

Ma allora, queste interfacce a cosa servono? A differenza dell'uso comune delle interfacce che è quello di rappresentare servizi comuni offerti da diverse implementazioni, in questo caso si limitano a rappresentare un pattern, un modello che gli sviluppatori di .NET Data Provider (nel nostro caso Microsoft e Oracle) devono seguire per garantire una uniformità nel disegno dei vari provider e quindi anche una certa similitudine che aiuta gli sviluppatori a comprendere ed imparare più facilmente l'utilizzo di diversi provider.



INDIPENDENZA DALLA BASE DATI?

Questo argomento spesso dibattuto merita una nota alla luce delle novità introdotte anche da ADO.NET.
Poter sviluppare una applicazione impiegando un Data Base, magari Oracle, e poi modificarla perché funzioni con un altro Data Base, magari SqlServer o IBM DB2, è un desiderio diffuso. Progettare dall'inizio una applicazione perché possa funzionare con diversi Data Base è possibile ma richiede maggiori risorse, costi e tempi. Perché non è possibile ottenere gratuitamente il risultato? Diversi Db Server supportano l'SQL standard ANSI, tuttavia tale standard non è motivato dalla interoperabilità (come per esempio gli standard dei protocolli Internet) ma dalla necessità di uniformità per non disorientare gli utenti e per avere una base comune su cui ricerca accademica ed industriale possa impegnarsi (come accade nella crittografia). Ne consegue che ogni Data Base può implementare in maniera parziale lo standard e prevedere estensioni personalizzate:
In pratica il minimo comune denominatore dei vari Data Base è un insieme sensibilmente ridotto di funzionalità. Osservando i prodotti sul mercato si scopre che alcuni si sono rassegnati e hanno rinunciato ai vantaggi derivati dall'uso esteso delle specifiche funzionalità di una marca di db accontentandosi di fare un uso limitato delle funzionalità pur di ottenere la compatibilità con molti Data Base. Altri hanno progettato l'applicazione prevedendo un livello sostituibile a seconda del Data Base impiegato pur di ottenere la compatibilità con alcuni Data Base.  Tutti gli altri ha preferito rinunciare alla compatibilità con più Data Base.


P   a   r   t   e   1          -          P   a   r   t   e       2          -          P   a   r   t   e       3          -          P   a   r   t   e       4