Accéder à  l’iSeries en utilisant .NET Data Provider d’IBM

Les applications Microsoft .NET utilisent ADO.NET pour connecter des applications
aux sources de données
cible. Conçu principalement pour
traiter les applications Web et distribuées,
ADO.NET est constitué
d’un ensemble de classes ou de namespaces
dans le .NET Framework.
Cet ensemble donne aux applications
.NET le moyen d’accéder
aux données et de les gérer. ADO,
le prédécesseur direct d’ADO.NET,
était principalement conçu pour
un style d’applications client/serveur
à  deux niveaux. Ce procédé ouvre une connexion à  la base de données
quand l’application démarre puis garde cette connexion ouverte jusqu’à  la fin
de l’application. Cette technique convient pour la plupart des applications de
style intranet, où le nombre total de connexions client est une quantité connue
et l’état de l’application est généralement contrôlé par elle-même et est aussi
une quantité connue. Mais cette méthode s’est heurtée à  de graves limitations pour des applications de style Web
à  n niveaux (n-tiered). En effet,
comme le Web est un environnement
public, le nombre total de
connexions ouvertes que les applications
Web nécessitent n’est pas
une quantité connue et varie considérablement.
A un instant donné,
une application peut n’avoir besoin
que d’une poignée de connexions
qui deviendront des milliers après
quelques minutes. Dans ce genre
d’environnement, il est difficile de
garder des connexions ouvertes
pour plusieurs raisons : chaque
connexion doit s’initialiser avec la
base de données d’arrière plan, ce
qui constitue une opération
lourde ; et chaque connexion ouverte
demande que les ressources
système restent ouvertes, réduisant
du même coup les ressources offertes
aux autres opérations de la
base de données.
Microsoft a conçu ADO.NET
pour répondre au scénario déconnecté inhérent aux applications Web.
Ce modèle déconnecté permet à 
ADO.NET de s’adapter immédiatement
aux applications d’entreprise,
parce qu’une connexion ouverte n’est
pas maintenue entre chaque système
client et la base de données. Les choses
se passent plutôt ainsi : quand une
connexion client est initiée, une
connexion à  la base de données est ouverte
brièvement, les données demandées
sont extraites du serveur base
de données et la connexion est fermée.
Après quoi, l’application client utilise
les données en toute indépendance
par rapport au serveur base de données.
L’application client peut naviguer
dans son sous-ensemble de données,
les modifier et les données restent
« cachées » chez le client, jusqu’à  ce
que l’application indique qu’elle doit
retransmettre les changements au serveur
base de données. Ensuite, une
nouvelle connexion est ouverte vers
les serveurs, et tous les changements
apportés par l’application client sont
répercutés dans la base de données
dans un batch de mise à  jour, et la
connexion est fermée.
Le DataSet est l’objet ADO.NET
central qui permet ce scénario déconnecté.
Le DataSet est une sorte de base
de données miniature en mémoire qui
est maintenue indépendamment de la
base de données d’arrière plan. Des
connexions vers la source de données
sont ouvertes pour peupler le DataSet
ou pour transférer dans la base de données
les changements effectués dans le
DataSet. Ce scénario déconnecté réduit
l’overhead système et améliore le
débit et l’évolutivité des applications.
La base de données en mémoire
du DataSet ADO.NET offre bon nombre
des fonctions que vous trouverez
dans une vraie base de données, y
compris le support pour des relations
de données, des contraintes de données,
des contraintes de clé étrangère
et la possibilité de créer des vues.
Cependant, s’agissant d’une structure
en mémoire, elle ne prend pas en
charge beaucoup des fonctions base
de données plus avancées qui caractérisent
des bases de données de niveau
entreprise. Ainsi, le DataSet ignore les
déclencheurs, les procédures stockées,
et les fonctions définies par l’utilisateur.
La figure 1 donne une
meilleure idée d’ensemble de l’architecture
ADO.NET.
ADO.NET est mis en oeuvre comme
un ensemble de classes qui existent
dans le .NET Framework. Les classes
Microsoft d’ADO.NET sont groupées
au-dessous du namespace System.
Data de .NET Framework. Plusieurs namespaces
importants constituent la
technique d’accès aux données ADO.
NET. Tout d’abord, les Microsoft .NET
Data Providers sont implémentés
dans des namespaces System.Data.
SqlClient, System.Data. OracleClient,
System.Data.OleDbClient et System.
Data.Odbc. Pour eux, iSeries Access
ajoute le DB2 UDB for iSeries .NET
Data Provider. Les .NET Data Providers
donnent à  la base de données sous-jacente
la connectivité que nécessitent
tous les autres objets ADO.NET.
Les classes dans ces .NET Data
Providers permettent aussi d’exécuter
des commandes, d’extraire des données
dans un style d’accès avance rapide seulement et de charger les
ADO.NET DataSet. Les classes de namespaces
System.Data peuvent être
considérées comme le coeur d’ADO.
NET et elles prennent en charge la
nouvelle classe ADO.NET DataSet.
Etant en stockage de données en mémoire,
le DataSet est constitué d’une
collection de classes supportant des
tables, des colonnes, des contraintes,
des lignes, et des relations, et des objets
DataTables, DataColumns, Data-
Constraints, DataRows et DataRelations
nommés de façon appropriée.