Mon aperçu des fournisseurs de données .Net et ADO.Net est-il correct?

Question

Récemment, j'ai dû taper de la documentation sur les fournisseurs de données .net et sur ado.net. J'essaie d'obtenir des commentaires sur mes conclusions. S'il vous plaît examiner et fournir des corrections ou des opinions.

Résumé Ceci est un résumé de haut niveau de l'API .Net de base pour interagir avec une base de données. En tant que développeur avec principalement un environnement Java et PHP, je n'étais pas clair sur la façon dont ADO.Net lié à OleDb et je n'avais aucune idée de ce que l'on entendait par le terme "fournisseur de données .Net". J'ai créé ceci parce que la documentation de msdn est HEAVILY concentrée sur ADO.Net et ne donne pas une image claire de la manière dont les nombreux espaces de noms, interfaces et classes interagissent.

.Net Data Provider

• http://msdn.microsoft.com/en-us/library/a6cd7c08(v=VS.71).aspx
• Un fournisseur de données .NET Framework est utilisé pour la connexion à une base de données, commandes d'exécution, et la récupération résultats. Ces résultats sont traités directement par ou placés dans un ensemble de données ADO.NET . Cela signifie que .Net Data Provider implémente les interfaces définies dans l'espace de noms System.Data .
• Un fournisseur de données .Net est similaire à un pilote JDBC en Java

System.Data

• http://msdn.microsoft.com/en-us/library/system.data.aspx Cette page contient du texte qui fait vous pensez que ADO.Net est le CORE partie de l'accès aux données .Net, cependant la réalité est que ADO.Net est le plus haut niveau d'accès aux données et est reposant sur les fournisseurs de données .Net qui implémentent les interfaces dans le fichier système .
• À mon avis, il semble presque comme Microsoft tente de cacher le fonctionnement des connexions de base de données , de sorte que les utilisateurs sont piégés à l'aide des contrôles fournis par Visual Studio. Le System.Data namesapce contient interfaces qui doivent être définies par ALL .Net fournisseurs de données

System.Data base Interfaces

• IDbConnection
• IDbCommand
• IDataAdapter
• IDataReader

Exemples de système.Implémentations données

• Les espaces de noms suivants comprennent des classes qui mettent en œuvre le noyau des interfaces « .Net données Provider » définis dans System.Data
• System.Data.SqlClient
• System.Data.OLEDB
• System.Data.Odbc
• IBM.Data.DB2
• ByteFX.Data.MySqlClient

ADO.Net

• http://msdn.microsoft.com/en-us/library/27y4ybxw(v=VS.71).aspx
• ADO.Net est une requête de base de données et API de manipulation construite au-dessus des classes .NET Data Provider base . ADO.Net se concentre sur l'interaction de base de données multi-niveaux déconnectée, . À mon avis les classes de base ADO.Net devraient être dans un espace de noms séparé comme System.Data.ADO juste dans un souci de clarté.

Classes Core ADO.Net

• DataSet
• DataTable
• DataColumn
• DataRelation

Answer 1

System.Data est le "paquet" qui contient tout pour travailler avec des "fournisseurs de données" .NET. Il est vrai que ADO, est une stratégie pour travailler avec des données, mais c'est la stratégie principale dans .NET.

ADO est moins sur les technologies DB spécifiques (car il n'est pas nécessairement destiné à être une technologie spécifique à la base de données) et plus sur les relations de données. Les termes: Set, Table, Column, Row et Relationship sont des termes de modélisation bien compris et ADO.NET en fait des objets de première classe dans l'espace .NET. Les fournisseurs de données fournissent des détails spécifiques à l'implémentation de bas niveau pour la prise en charge des concepts ADO.NET principaux (tables, lignes, etc.) et sont destinés à éliminer les détails d'implémentation directe de la connexion à un fournisseur de données. Par exemple, vous devriez être en mesure, avec un minimum d'efforts, d'échanger un fournisseur Jet Data, avec un fournisseur de données Oracle, en termes de DataTables, DataRows et DataColumns (détails de la requête), afin que votre code soit minimisé. changement. Pourquoi est-ce important? Parce que cela signifie que vous pouvez travailler avec des sources de données non homogènes avec une sémantique de commande similaire (c'est-à-dire que vous pouvez travailler avec des feuilles de calcul Excel et MySQL DB dans la même application avec les mêmes objets). Cela rend la réutilisation et la réaffectation très facile et très simple.

En vue générale, vous pouvez penser du système de cette façon:

1. Le fournisseur de données .NET est où vous obtenez vos données à partir. Vous devrez importer du système.Données de chaque fournisseur utilisé par votre application
2. Les classes ADO.NET sont les concepts avec lesquels vous allez travailler avec Tables, Lignes, Colonnes, etc. Elles n'ont rien à voir avec les requêtes, les index, etc. Ce sont les détails du fournisseur.
3. Votre application ne devrait que rarement (je dirais jamais, mais il y a toujours des exceptions) avoir besoin de connaître le fournisseur et de se concentrer sur la consommation et la production de DataSets, DataTables, etc

Hope that helps.

Answer 2

En ce qui concerne:

À mon avis, il semble presque comme Microsoft tente de cacher la façon dont le travail des connexions de base de données , de sorte que les utilisateurs sont piégés à l'aide des contrôles fournis par Visual Studio.

L'existence de fournisseurs tiers ne supporte pas l'idée que MS tente de nous «piéger» dans quoi que ce soit. Cacher "comment fonctionnent les connexions à la base de données" est une sorte d'abstraction, et n'est pas subversive.