Discussion :

[PlayerOne]

Bonjour,

Profitant de l'été pour dépoussiérer les connaissances, je suis en train de travailler sur une classe de gestion des accès aux bases de données.

Les objectifs sont les suivants :

1. Etre générique autant que possible (utilisation de DbProviderFactory, DbConnection, DbCommand etc.)

2. Encapsuler et simplifier l'exécution des requêtes, des procédures stockées, la gestion des paramètres

3. Servir à gérer les accès BDD dans une couche DAO par exemple avec une ou plusieurs bases de données

La classe DataProvider du tutoriel suivant m'a servi de base :

http://johannblais.developpez.com/tu...acces-donnees/

Dans un premier temps, j'utilise comme dans le tutoriel des méthodes statiques afin d'optimiser les performances.

Le problème, c'est que si je veux utiliser des bases de données différentes dans un projet, j'ai un soucis avec la configuration de la chaîne de connexion.

En effet, je ne me vois pas changer la chaîne de connexion chaque fois que je veux exécuter une requête.

J'avais pensé faire une classe de base et faire de l'héritage pour avoir deux classes héritée distinctes avec une chaîne de connexion différente. Malheureusement, vu que les propriétés et méthodes sont statiques, cela ne fonctionne pas...

Pour l'instant, je sèche et ne vois que deux pistes :

Changer les méthodes statiques par des méthodes normales et configurer la chaîne de connexion dans le constructeur par exemple, mais cela m'obligera à instancier la classe chaque fois que j'ai besoin de faire un accès à la base de données.

Ou bien utiliser la solution précédente, mais avec une classe de type singleton pour chaque base de données afin de limiter les créations et destructions d'objets. Seulement, l'utilisation d'un singleton pour gérer les accès aux bases de données semble déconseillé (surtout en ASP.NET), bien que je ne vois pas de différence flagrante au niveau du fonctionnement par rapport aux méthodes statiques...

Copier comme un porc ma classe actuelle avec ses méthodes statiques me semble contraire à tous les principes de la POO

Une idée pour résoudre le problème de façon élégante ?
Ou bien, est-ce que je me prend la tête pour rien, et créer et détruire sans arrêt des objets d'accès aux données comme avec Data Application Block ou Enterprise Library n'est pas si grave en terme de performance ?

Merci de votre aide

[laedit]

Je pencherais pour la première solution, faire une classe non statique en passant la chaîne de connexion dans le constructeur.

Il faudra seulement instancié un objet par base de données que tu veux utiliser.

Ce qui est, somme toute, assez logique.

[tomlev]

Je pencherais pour la première solution, faire une classe non statique en passant la chaîne de connexion dans le constructeur

oui, c'est clairement la meilleure option

Par contre, si tu veux faire un truc complètement générique, tu vas quand même rencontrer pas mal de problèmes :
- Tous les SGBD ne supportent pas le même dialecte SQL. Certaines clauses existent sur un SGBD et pas sur un autre (ex. le CONNECT BY d'Oracle), ou encore certaines fonctions sont différentes (NVL sur Oracle, ISNULL sur SQL Server)
- La syntaxe pour les paramètres de requête n'est pas toujours la même. Certains SGBD utilisent "@nom", d'autres ":nom", certains "?" (pas de nom)... en plus, certains font la liaison des paramètres par nom, d'autres par position...

Bref... c'est un enfer

A mon avis, pour pouvoir faire vraiment abstraction du SGBD, il faut utiliser un ORM, genre NHibernate ou Entity Framework

[laedit]

A mon avis, pour pouvoir faire vraiment abstraction du SGBD, il faut utiliser un ORM, genre NHibernate ou Entity Framework

J'approuve, c'est en tout cas le plus facile.

Sinon, dans ta classe générique tu prendra en compte un paramètre indiquant le type de moteur SQL utilisé (MySQL, SQLite, SQL Server, Oracle, etc...) et dans pas mal de tes fonctions, tu te retrouveras avec un switch pour écrire tes requêtes en fonction du moteur.

J'en ai fait une qui gère seulement MySQL et SQLite et je me suis rapidement retrouvé avec beaucoup de code pour pas grand chose.

[Philippe Vialatte]

+1

Si tu veux voir la prise de tête que c'est de gerer tous ces dialectes, recupere le code source de NHibernate ou de Subsonic, et jette un oeil aux providers...

Grosso modo, tu dois te taper un provider par base de donnees...

Si c'est un projet perso, base toit sur un des deux projets existant, ca devrait bien t'aider...

Si c'est pour le travail, je te deconseille de paser du temps a reinventer un ORM

[PlayerOne]

Merci pour vos réponses.

Je garde la partie générique pour la base, genre je l'utilise comme brique d'accès dans ma couche DAO, en lui passant les requêtes SQL ou le nom des procédures stockées en paramètre.

Je n'ai pas prévu d'aller jusqu'à rendre la partie SQL générique car je suis bien conscient que ceci sera très difficile en raison de l'implémentation SQL différente selon le SGBD (Transact SQL, PL/SQL...) et très chronophage.

De toute façon, je travaille principalement avec SQL Server... Au pire je m'amuserai avec le SQL quand j'aurais l'occasion de passer sur Oracle ou un autre SGBDR, en fonction de la motivation ou du temps libre

La classe est pour des projets persos pour le moment mais sera de toute façon réutilisée ou modifiée si besoin pour le travail.

Mais effectivement, je n'irai pas jusqu'à réinventer un ORM, ce qui serai inutile et contre productif. Je vais quand même jeter un coup d'oeil à NHibernate, histoire d'avoir une alternative.

Entre les trois choix de base, je me demandais lequel était le plus élégant en terme de simplicité et de performance. Je me demande si le fait de créer sans arrêt des objets d'accès ne risquait pas de gêner les performances en cas de montée en charge, sur un projet ASP.NET par exemple (d'où le départ sur une classe avec des méthodes statique).