[Connection DB] Bien gérer les connexions !

Bonjour,

Je me posais la question sur quelle est la meilleure manière de gérer les connexions à la base.

Vaut-il mieux faire comme je l'ai vu dans certains tutoriaux des classe Factory où on gère la connexion ?
Est ce une bonne pratique d'utiliser pour cette classe le DP singleton ? (Je pense au cas ou on aurait une évolution un moment donné qui fait qu'une requête engendre une autre et que les deux doivent s'exécuter en parallèle, on serait obliger de refaire la logique ou je me trompe ?)

Ou encore utiliser un Scope de connexion ?

Ou encore avoir une classe avec les méthodes statiques qui vont bien ?

Utilisez-vous Global.asax pour partager la connexion ?

Ou encore vous préférez créer directement dans votre code la connexion ?

Bien que cela dépend souvent de l'utilisation et le contexte, je suppose que y a des bonnes pratiques qui s'adaptent à la plupart des situations, si vous les connaissez n'hésiter à les faire partager.

Merci à tous ceux qui me liront et ceux qui répondront.

Vu qu'il y a pas de réponse à ma première requête.

Il est peut être plus approprié de vous donner un cas (qui pourrait peut être bientôt m'arriver) :mouarf:

Dans mon architecture actuel, j'utilise une classe (Factory) donc laquelle je gère la connexion, cette classe applique le design pattern Singleton.

Jusqu'ici, cette architecture répond parfaitement à mes besoins. Mais ça pourrait se corser bientôt.
Supposant que je veuille remplir les données d'une équipe (dans ma base j'ai Une table équipe et une table joueur, l'objet équipe comporte une list<> de joueurs), si je veux remplir une liste d'équipe (disant pour le besoin d'un championnat), je dois alors :

Dans ma logique (qui n'est peut être pas la bonne d'ailleurs) ce qu'il me faut faire c'est une requête pour récupérer les données d'une équipe, ensuite lancer une requête pour récupérer les joueurs d'une équipe et enfin ajouter l'équipe à la collection, de même pour les autres équipe.

Ce qui m'oblige à avoir deux connexions (une pour équipe et une autre pour joueurs) car on ne peut utiliser dans une connexion qu'un seul DbDataReader :oops:

Donc, ou je remets en question mon architecture ou ma logique :aie: car soit :

- J'utilise un pool de connexion.
- Soit je rempli les équipes (sans joueurs) et je ferme mon datareader. Ensuite je rempli les joueurs pour chaque équipes.

Code:

---

1 2	foreach (Equipe equipe in equipes) remplirJoueur(Equipe);

---

Soit y a une méthode secrète que je n'ai pas encore trouvé qui me permets de garder ma logique et mon architecture. Et dans ce cas je serais soulager de la connaitre.

Merci aux âmes charitable qui pourront m'éclairer et atténuer mon ignorance.

Tu peux définir dans ta chaine de connexion qu'une requête peut renvoyer plusieurs resultsets. Ensuite il suffit de créer une dbcommand qui contient deux requêtes à la suite, le datareader obtenu pourra te servir pour les deux resultset retournés.

Citation:

---

Envoyé par SaumonAgile

Tu peux définir dans ta chaine de connexion qu'une requête peut renvoyer plusieurs resultsets. Ensuite il suffit de créer une dbcommand qui contient deux requêtes à la suite, le datareader obtenu pourra te servir pour les deux resultset retournés.

---

oui sauf que pour avoir les joueurs je dois savoir pour quel équipe, donc chaque résultat de la premiére requête conditionne une nouvelle requête (qui récup les joueurs). Ou peut être j'ai mal compris ta suggestion.

Merci pour ta réponse en tt cas.

Pourquoi ne pas faire une seule requête qui renvoie les équipes et les joueurs ?

Citation:

---

Envoyé par SaumonAgile

Pourquoi ne pas faire une seule requête qui renvoie les équipes et les joueurs ?

---

Comment tu voix la chose ?

Je fais une jointure, avec pour chaque joueur d'une équipe une ligne avec la répétition des données de l'équipe :

(equipe1, president1, stade1, joueur1, poste1, age1)
(equipe1, president1, stade1, joueur2, poste2,age2)
...

Puis pour remplir je dois tester pour savoir quand j'arrête de remplir une équipe et passer au suivante ?

C'est ça ou je me trompe ?

Merci encore pour ta réponse.

Effectivement, tu peux faire ça de cette manière.

Citation:

---

Envoyé par SaumonAgile

Effectivement, tu peux faire ça de cette manière.

---

Merci bcp pour ta réponse.

Mais, c'est la solution qui me semble la moins adéquate, je me trompe peut être.

Ce que je fais actuellement, c'est remplir toutes les équipes (en laissant vide la List<> Joueurs) ensuite j'appel une méthode qui rempli les List<> Joueurs de chaques équipe.

Pas totalement convaincu, mais bon.

PS : Merci encore SaumonAgile :king:

Citation:

---

Envoyé par rad_hass

Ce que je fais actuellement, c'est remplir toutes les équipes (en laissant vide la List<> Joueurs) ensuite j'appel une méthode qui rempli les List<> Joueurs de chaques équipe.

Pas totalement convaincu, mais bon.

PS : Merci encore SaumonAgile :king:

---

Au pire, si tu ne veux pas le faire en une seule requête, tu peux le faire en deux requêtes maximum.
1. Tu récupères les équipes
2. Tu récupères les joueurs de toutes les équipes renvoyées en 1.
3. Tu consolides (j'utilise des Dictionary pour faire ça)

ce que tu traite au final c'est la seconde requete dns ton programme, la premiere ne sert qu'a alimenté la premiere...

tout le traitement pour déterminer ce qui découle dans la deuxieme de la première peut être a mon sens apparenté à un traitement SQL...

pour ne pas tout simplement utiliser une procedure stockée.
Ensuite ta procédure peut retourner plusieurs résultset c'est pas interdit, ils serons modélisé comme 2 tables dans un dataset ou dans le datareader... rien de très exceptionnel en somme.

Ainsi si ta requet est paramètrées et que les paramètres fourni a la procédure suffisent à trouver le second resultset.. tu n'a plus 2 DataReader.
Sinon oui tu peux multiplier les connexions.

Il faut savoir une chose. Si tu clos le premier datareader, pour ensuite utiliser le second, déja tu dois impérativement garder e mémoire le premier résultat.. mais ca c'est pas le probleme, le problème c'est qu'entre le moment, où tu va fermer le premier et extraire le resultset, la base de donnée peut avoir changé d'état et les données que tu avait dans ton premier resultset ne plus etre valable pour le second... n'oublie pas que visiblement tu travail dans une architecture web... il faut donc tenir compte des accès concurrent à la base de données.

Là encore la solution est de mettre une transaction, ouvrir un dr, le refermer, en ouvrir un second...
en assurant que la transaction et de type sérialisée, ou faire une procédure qui assure que toute autre exécution sera sérialisée.... une procédure est gérée comme une transaction à part entière... de toute facon tu peux au sein d'une procédure stockée créer une transaction.

Merci beaucoup pour ta réponse.

Citation:

---

Envoyé par cinemania

ce que tu traite au final c'est la seconde requete dns ton programme, la premiere ne sert qu'a alimenté la premiere...

---

Certe j'utilise le numéro d'équipe pour récuperer les joueurs, mais j'ai besoin des informations lié à l'équipe, car au finale je récupere les infos de l'équipe + les joueurs.

Citation:

---

tout le traitement pour déterminer ce qui découle dans la deuxieme de la première peut être a mon sens apparenté à un traitement SQL...

pour ne pas tout simplement utiliser une procedure stockée.
Ensuite ta procédure peut retourner plusieurs résultset c'est pas interdit, ils serons modélisé comme 2 tables dans un dataset ou dans le datareader... rien de très exceptionnel en somme.

---

J'avoue que la je comprends moins, 2 tables dans mon datareader ? Je pourrais donc faire :

Code:

---

1 2	reader["id_equipe"] reader[0]["id_joueur"]

---

Enfin je voix pas trop.

Citation:

---

Il faut savoir une chose. Si tu clos le premier datareader, pour ensuite utiliser le second, déja tu dois impérativement garder e mémoire le premier résultat.. mais ca c'est pas le probleme, le problème c'est qu'entre le moment, où tu va fermer le premier et extraire le resultset, la base de donnée peut avoir changé d'état et les données que tu avait dans ton premier resultset ne plus etre valable pour le second... n'oublie pas que visiblement tu travail dans une architecture web... il faut donc tenir compte des accès concurrent à la base de données.

---

Il est vrai que j'ai pensé à faire une transaction, mais il n y a quasiment pas de suppression dans la base ... Il y a un changement de statut. Mais il serait peut être plus intérescent de faire une transaction pour le "On sait jamais"