Accès aux données en .NET (ADO.NET) Introduction L'accès aux données est un élé
Accès aux données en .NET (ADO.NET) Introduction L'accès aux données est un élément important dans la majorité des applications développées aujourd'hui. Microsoft a proposé une panoplie de technologies d'accès aux données (ODBC, DAO, RDO, ADO). ADO.NET (anciennement appelé ADO+) constitue la dernière technologie proposée dans ce cadre. Rappel Terminologie • API (Application Programming Interfaces) : une API est une bibliothèque de modèles de fonctions (interfaces) généralement de bas-niveau réalisant une tâche bien précise. Dans un contexte orienté objet, une API se présente comme une bibliothèque de classes interfaces disposant de méthodes permettant de réaliser des tâches bas-niveau. • API d'accès aux données : Une API d'accès aux données est une bibliothèque de fonctions ou d'objets permettant de faire les opérations d'accès aux bases de données, d'interrogation de ces bases (envoi des requêtes) et de récupération de données à partir de ces bases. • API native d'accès aux données : Chaque SGBD possède une API propriétaire tenant compte de ses spécificités et qui permet de faire les opérations d'accès à cet SGBD. Une telle API est appelée une API native. ODBC (Open Data Base Connectivity) ODBC (Open Data Base Connectivity) est une API de fonctions (non orientée objet) unifiée d'accès aux données qui a pour objectif de permettre l'accès à n'importe quel SGBD sans nécessiter une connaissance des API natives. Architecture d'un pont ODBC : Un pont ODBC est composé de trois couches : • La première couche est une couche de réception des requêtes adressées par les applications à un SGBD. Ces requêtes sont spécifiées par les applications à l'aide de l'API ODBC. • La deuxième couche est constituée d'un composant logiciel appelé gestionnaire de pilotes. Ce gestionnaire joue le rôle d'intermédiaire qui va décider du choix du pilote ODBC approprié qui va prendre en charge la requête adressée par l'application. Ce choix se base sur le type de la base de données interrogée. Le Pont ODBC Requête utilisateur (API ODBC) Requête utilisateur SGBD SQLServe SGBD Oracle SGBD Access (API native) Requête utilisateur (API native) Requête utilisateur (API native) Requête utilisateur (API native) SGBD X © Karim Kalti 80 gestionnaire assure le chargement en mémoire et la libération du pilote sélectionné. • La troisième couche assure la communication entre le gestionnaire des pilotes et les pilotes ODBC. Cette communication est faite à travers des appels effectués par le gestionnaire, aux fonctions des pilotes ODBC. Ces fonctions font partie de l'API unifiée définie par le standard ODBC et utilisée par les développeurs des pilotes ODBC. Application API ODBC Gestionnaire de pilotes API Pilotes fournisseurs Pilote ODBC Pilote ODBC Pilote ODBC Pilote ODBC SGBD 1 SGBD 2 SGBD 3 SGBD 4 Architecture d'un pont ODBC Pilote ODBC Un pilote ODBC est un composant logiciel qui a pour objectif de traduire la requête écrite avec l'API ODBC unifiée vers un format (écrit à l'aide de l'API native) propre au SGBD interrogé. Tout SGBD qui veut être accessible à travers ODBC doit fournir un pilote ODBC qui lui est spécifique. Ainsi par exemple, pour accéder à une base de données SQLServer ou Oracle à travers ODBC, il faut installer sur la machine sur laquelle tourne l'application le pilote ODBC pour SQL Server, respectivement pour Oracle. Pour voir sous Windows XP la liste des pilotes ODBC installés sur une machine il faut aller à : Panneau de configuration → Outils d'administration → Sources de données ODBC OLE DB : OLE DB (Open Linking and Embeding for DataBases) est une API unifiée d'accès aux données qui offre plus de possibilités que l'API ODBC. En effet ODBC permet l'accès aux bases de données relationnelles seulement. Avec OLE DB il est possible d'accéder à n'importe quelle source de données, relationnelle ou non (Système de fichiers, XML, Tableur, Messagerie,…). OLE DB utilise une collection d'objets qui définit un modèle différent de celui de ODBC. Ce modèle s'articule autour des objets de base suivants : Data Source, Session, Command, Rowset. A ces objets de base s'ajoutent d'autres objets qui sont : Enumerator, Transaction, Error. © Karim Kalti 81 SGBD-R Avantages et inconvénients de l'utilisation des APIs unifiées. Sans l'utilisation d'une API unifiée, les programmeurs d'applications sont obligés d'appendre différentes API natives pour faire des accès à différents SGBDs. Ceci alourdit la charge de travail des développeurs surtout dans les milieux professionnels où l'on est amené souvent à travailler sur des SGBD différents d'un projet à un autre. L'intérêt des APIs unifiées dans ce cas est grand puisqu'elles vont alléger la charge de travail des développeurs. Les APIs unifiées sont toutefois moins rapides que les API natives à cause notamment des étapes de conversion de requêtes qui sont nécessaires dans ce cas. Présentation de ADO.NET ADO.NET (ActiveX Database Object) est une nouvelle API d'accès aux données proposée par Microsoft. Cette API permet aux applications développées en .NET de travailler avec différents types de sources de données. Caractéristiques : • ADO.NET permet de travailler en mode connecté et en mode déconnecté. • ADO.NET permet de travailler d'une manière complètement indépendante du type de la base de données. • ADO.NET permet l'interopérabilité avec d'autres sources de données (relationnelle ou non telles que les systèmes de fichiers, Active Directory, etc.). Cette interopérabilité est obtenue grâce à la possibilité d'importer et d'exporter les données au format XML. Configuration requise pour ADO.NET • ADO.NET est fourni avec le FrameWork.NET. • Il est nécessaire par ailleurs d'installer MDAC (Microsoft Data Access Components version 2.6 ou plus) pour pouvoir utiliser les fournisseurs de données SQL Server ou OLE DB. • ADO.NET peut être utilisé sous Windows CE/95/98/ME/NT4 SP6a/2K/XP/2003 Server. Les modes de travail avec ADO.NET ADO.NET offre deux modes de travail : Le mode déconnecté Ce mode permet de travailler d'une manière déconnectée de la source de données. Les étapes de travail avec ce mode se déroulent comme suit : • Le client entre en communication avec le serveur de BD pour effectuer une requête (généralement un SELECT). • Le serveur envoie en une seule fois le résultat de la requête au client et la communication est ensuite coupée. Le client dispose donc d’une copie locale d’une partie de la BD serveur (qui correspond à sa requête). • Le client peut travailler sur la copie locale sans solliciter ni le serveur ni le réseau. Il peut modifier cette partie puis l’envoyer à nouveau au serveur à travers une nouvelle connexion à la BD. Pont OLE DB API OLE DB XML Fichiers Tableur Autres Exemples de sources de données accessibles à travers un pont OLE DB © Karim Kalti 82 Le mode connecté Ce mode permet de travailler d'une manière connectée par rapport à la source de données. Les étapes de travail avec ce mode se déroulent comme suit : • Le client effectue une requête auprès du serveur (Exemple un SELECT). • Le serveur calcule le résultat de la requête, il maintient une communication logique avec le client et lui envoie le résultat de son SELECT ligne par ligne suite aux demandes de ce client (déplacement entre les enregistrements de son RecordSet). • Le serveur doit savoir où il en est dans sa communication avec chaque client qui lui est connecté. Comparaison des deux modes • Le mode déconnecté est plus adapté à la manière de travailler sur Internet. En effet sur Internet on ne peut pas connaître quand est ce que le client (léger dans ce cas) décide de se déconnecter de la page d'accès aux données (Il peut la laisser ouverte et passer à d’autres pages). Maintenir plusieurs connexions ouvertes en continue avec la source de données constitue un frein à la capacité de montée en charge d'une application. (ce problème peut toutefois être évité en utilisant la propriété TimeOut liée à la variable de Session). • Le mode déconnecté engendre une plus grande surcharge du réseau mais seulement au moment de la transmission du résultat de la requête ce qui risque de provoquer des courts blocages. • Le mode connecté est préféré lorsque le jeu d'enregistrement à traiter est trop grand pour être facilement transféré et stocké localement en mémoire. Architecture générale de ADO.NET ADO.NET est une API composée d'une collection de classes interfaces répartie suivant un modèle en deux couches comme le montre la figure ci-dessous : Les deux couches qui composent ce modèle sont : • Une couche connectée qui comporte des classes managées qui font des accès physiques à la base de données. Ces classes constituent ce que ADO.NET appelle un fournisseur de données ou Data Provider (Connection, Transaction, Command, Parameters, DataReader, DataAdapter,…). • Une couche déconnectée qui comporte des classes qui ne sont pas en liaison directe avec les bases de données. Ces classes constituent une sorte de cache pour le stockage en local d'une partie des données de la base. © Karim Kalti 83 Le modèle de fournisseur de données Un fournisseur de données est une API qui permet de faire des accès physiques à la source de données. Cette API est composée de la collection de classes interfaces de la couche connectée de ADO.NET. Les quatre objets de cette uploads/Management/ pont-odbc-terminologie.pdf
Documents similaires










-
34
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Aoû 20, 2021
- Catégorie Management
- Langue French
- Taille du fichier 0.5428MB