Bonsoir à tous,
Je me pose une petite question sur ADO.NET que j'utilise pas mal en C#.
Je travaille sur plusieurs types de bases de données (Access, ODBC et SQL Server).
J'ai remarqué que pour travailler avec chaque de ces bases, les commandes sont à peu près les mêmes.
Par exemple, pour la connexion à une base de données, on utilise :
- avec ODBC, on utilise OdbcConnection connection = new OdbcConnection(connectionString);
- avec SQL, on utilise SqlConnection connection = new SqlConnection(connectionString);

Existe-t-il des commandes communes à toutes les classes ADO (SQL, Access, ODBC...) pour se connecter sur une base, faire une requete, créer des DataReader ...
Le but étant de changer de pouvoir changer le type de BDD utilisé dans mon projet sans devoir tout retaper.

Merci d'avance pour vos suggestions

System.Data.Common.DbConnection est la classe de base pour SqlConnection, OdbcConnection, OleDbConnection et OracleConnection.

Bonsoir,
J'ai regardé la doc sur MSDN mais apparemment on est quand même obligé d'utiliser les méthodes propre à System.Data.Odbc.OdbcConnection ou System.Data.SqlClient.SqlConnection. Existe-t-il un moyen pour dire au début du programme, je travaille en ODBC ou en SQL et après j'utilise les mêmes commandes pour travailler sur la BDD (que ce soit en ODBC ou SQL) ?

Je sais pas exactement quelles sont les commandes spécifiques, mais tu pourrais créer ta propre classe dérivant de DbConnection avec une propriété spécifiant le type de connexion, et qui agit en conséquence ensuite...

Pendant ce temps, Entity Framework ...

A quoi ça sert exactement ?

Citation : tuto en cours de rédaction

Entity Framework est un framework de Mapping Objet-Relationnel (<acronym title="Object Relational Mapping">ORM</acronym>) : son but est de représenter une base de données comme un ensemble de classes et donc d'objets. Il sert à définir la relation d'équivalence (mapping) entre votre base de données relationnelle et votre modèle de données objet. Concrètement, cela signifie qu'au lieu de manipuler des tables et des records en SQL, vous manipulerez des classes et des objets en C#, et les changements seront répercutés sur votre base de données.

Les avantages de ce mécanisme sont nombreux :

• On n'écrit jamais de requêtes en SQL. On ne fait que du C#, et on s'en porte d'autant mieux. Du coup, le compilateur veillera à la validité de toutes nos requêtes.
• Puisqu'on n'écrit que du C#, les instructions de manipulation de données sont tout-à-fait indépendantes du <acronym title="Système de Gestion de Base de Données">SGBD</acronym> utilisé : le code sera exactement le même selon qu'on utilise SQL Server, Oracle ou encore MySQL par exemple.
• Les attaques par Injection SQL, c'est has-been.
• De bout en bout, on ne fait que de l'orienté objet. La conversion en données relationnelles est faite de manière transparente pour nous.
• En cas d'évolution dans la structure de nos tables, notre modèle de données objet peut rester le même ou être mis à jour automatiquement. Si nous changeons le nom d'une colonne par exemple, les mécanismes de refactoring de Visual Studio nous aideront à modifier le nom de la propriété correspondante partout dans notre code - si on le souhaite.
• La gestion de la connexion à la base de données est transparente. Plus besoin d'ouvrir la connexion avec une classe Connection spécifique, de se rappeler qu'il faut la fermer plus tard, plus besoin de trainer des chaînes de connexion dans son code.
• La création automatique de ce modèle objet consiste en réalité à créer une véritable Couche d'Accès aux Données, qui constitue le socle de notre application selon une architecture trois tiers. Aucun risque donc de retrouver des instructions SQL dans le code-behind de nos forms...

Bien entendu, rien n'est gratuit en ce rude monde... Il y a aussi quelques inconvénients qui valent la peine d'être signalés :

• Il faut un certain temps (pas bien long) à Entity Framework pour convertir vos objets en records de table et vice-versa.
• Tout le code SQL est généré à la volée avant d'être envoyé au serveur de base de données. Il y a donc un impact supplémentaire sur les performances, car non seulement il faut produire ce SQL mais en plus le SGBD ne peut pas calculer à l'avance le plan d'exécution des requêtes et doit donc le reconstruire à chaque fois.
• La (quasi) totalité de la logique attachée à nos données se trouve déplacée dans le code applicatif en C#.
• De même, la gestion de la sécurité est à prévoir essentiellement au niveau applicatif et non au niveau de la base.

Néanmoins, les performances accrues des SGBD et la simplicité extrême offerte par le paradigme orienté objet de bout en bout rendent ces inconvénients tout-à-fait acceptables la plupart du temps. En tout cas pour débuter dans l'emploi des bases de données en .Net, nous n'aurons franchement pas à nous en préoccuper.

Super. Je vais reprendre tout ça à tête reposée. Merci pour ton aide.

Bonsoir Aethec,
en fin de compte, je pense que je vais appliquer ta suggestion.
Je vais créer une classe dérivée de dbConnection. Suis-je obligé de réimplenter chaque méthode ? et comment puis-je spécifier le type de connexion à utiliser ?

Merci d'avance pour tes suggestions ou celles de quelqu'un d'autre.

Je crains que tu ne doive créer des méthodes privées pour chaque type de connexion, puis utiliser un paramètre dans le constructeur, et ensuite faire un switch dans toutes les méthodes.

Quelles sont les méthodes/propriétés spécifiques que tu veux utiliser qui ne se trouvent pas dans la classe DbConnection ?

Je vais utiliser ces méthodes/propriétés :
- close
- connectionString
- createCommand
- database
- DataSource
- open
- toString.

Aurais-tu un exemple pour 1 de ces méthodes ou propriétés ?

Toutes ces méthodes et propriétés sont disponibles sur une DbConnection...pas besoin de s'embêter...

Je n'arrive pas à faire fonctionner cette classe. Je vais avancer plus dans le tuto C# du siteduzero car je crois qu'il me manque pas mal de notions. Merci pour ton aide en tous cas.