Dernière née des méthodes d'accès aux données, ADO.Net s'est construite sur les bases d'ADO. Grosse évolution plutôt que révolution, cette technologie reprend plusieurs principes de son ancêtre, elle-même issue d'une suite de protocoles d'accès aux données.

Un peu d'histoire pour recadrer le tout

Le besoin de communiquer avec un SGDB n'est pas nouveau. Chaque système de bases de données possède ses propres méthodes d'accès, ce qui ne facilite pas les tâches des programmeurs désireux de s'y connecter. Ces "API" comme on les appelle ("Application Programming Interface") sont autant de syntaxes à maîtriser afin de communiquer avec chaque SGBD.

Certes ces fonctions offrent des performances intéressantes, puisque développées spécialement pour le SGBD en question. Cependant, certains développeurs ne verraient pas d'un mauvais oeil une standardisation du côté de ces API : C'est la naissance du protocole "ODBC" (Open Data Base Connectivity).

Première tentative de standardisation, ODBC réside en un ensemble de fonctions dites de "haut niveau", destinées à "attaquer" une base de données. Grâce à ce protocole, les développeurs n'ont plus à se soucier du SGBD sur lequel ils travaillent : Les fonctions d'accès restent les mêmes quelque soit la base de données.

Par la suite, une couche supplémentaire est venue se placer au-dessus d'ODBC. "RDO" (Remote Data Object), destinée cette fois à faciliter la vie des programmeurs Visual Basic, alors qu'ODBC se tournait davantage vers les programmeurs C/C++. Suite au succès du logiciel "Access", et toujours placée au-dessus d'ODBC, une autre technique d'accès (plus simple que celle du logiciel d'origine, "jet") fait son apparition : "DAO" (Data Access Object).

Conscient que suite à la multiplication des méthodes d'accès disponibles, la standardisation en prenait un coup, et souhaitant offrir une méthode de connection indépendante des sources de données, Microsoft tente d'unifier le tout une nouvelle fois et développe une API basée sur COM : "OLE-DB" (Object Linking And Embedding Database).

Enfin, Microsoft toujours, afin de faciliter la vie des développeurs qui peinent à écrire des fonctions "OLE-DB", dévoile la technologie ADO (ActiveX Data Object) qui permet d'accéder à diverses sources de données plus facilement (surtout en VB).

Deux modes de connexion

Si la notion de "jeux de données déconnectées" est apparue dans ADO 2.0 afin de soulager d'une part le serveur BD et d'autre part d'épargner la bande passante, ADO.Net est dès le départ conçu pour ce mode de fonctionnement. Le mode "déconnecté" permet au client d'effectuer des fonctions telles que le tri, le filtrage, sans avoir recours au serveur, grâce à une copie locale des données.
D'ailleurs, une des différences essentielles entre les objets de connexion ADO et ADO.net réside dans l'absence de la propriété "CursorLocation" dans cette dernière version. Nous verrons un peu plus loin comment ADO.Net opère pour éviter de manipuler des curseurs sur le serveur afin d'extraire des enregistrements d'une base de données.
L'avantage du mode "déconnecté" sur le mode "connecté" est évident, ce dernier utilisant une connexion permanente avec la base de données.

Autre avantage d'ADO.Net : Le support d'XML comme format d'échanges de données. Auparavant un recordset ADO était un objet qui passait difficilement les firewalls, de même pour les objets COM, difficiles à véhiculer sur le réseau. L'adoption d'XML comme format de transmission universel garantit une interopérabilité tant que le récepteur s'exécute sur une plate-forme disposant d'un analyseur XML.

Les objets DataSet et DataReader

Avant toute chose une application ADO.Net doit créer un objet de connexion. Selon le type de SGBD auquel nous souhaitons nous connecter, il faut employer soit l'objet SQLConnection, soit ADOConnection. Le premier permet de bénéficier de fonctions permettant de tirer les meilleures performances de SQL Server.

Deux objets permettent de manipuler des données extraites de notre source : DataSet (mode déconnecté) et DataReader (mode connecté).

DataSet est une copie en mémoire des données de la base. Il est en quelque sorte une vue déconnectée de la base. Une fois en mémoire, les informations du DataSet (provenant des "SELECT") peuvent être manipulées sans avoir recours à une connexion au serveur.

Nous nous demandions plus haut comment ADO.Net se passait de curseurs "serveur" pour extraire des enregistrements de la base de données. La solution repose sur l'objet DataReader. Particulièrement optimisé, ce dernier permet de parcourir les enregistrements en lecture seule, séquentiellement, et par défilement vers l'avant. Il est en fait l'équivalent du curseur à lecture seule avec ADO.

Exemple de code

Dans notre description du procédé de connexion entre une source de données et l'objet DataSet, nous avons omis de mentionner une brique pourtant nécessaire au bon fonctionnement de l'ensemble : L'objet DataSetCommand. Voyons quel rôle il joue :

Dim oDS as DataSet
Dim oCMD as SQLDataSetCommand

oDS = New DataSet
oCMD = new SQLDataSetCommand("Select * from employes", strConn)
oCMD.FillDataSet(oDS, "EmployeesList")

Dim oRow as DataRow
For Each oRow in oDS.Tables(0).Rows
Console.WriteLine(oRow(0).ToString())
Next

DataSetCommand est nécessaire pour créer et initialiser les différentes tables, il permet également la récupération et l'enregistrement des données entre notre DataSet et la source de données. Il endosse aussi la responsabilité des opérations de mises à jour, d'insertions ou de suppressions appliquées à la base de données.

C'est tout pour cette fois-ci, cette présentation d'ADO.Net, non exhaustive, touche à sa fin. Trop vaste pour être abordée dans un seul article, seuls quelques grands principes ont été évoquées ici.