Discussion :

[Philace86]

Bonjour,
Tout d'abord, pour commencer, et cela peut légèrement conditionner vos réponses, sachez que je me qualifie de "bidouilleur" web (en effet je maîtrise certain language de programmation mais pas particulièrement l'ASP.NET). Bien ceci étant dis voici ma problèmatique, j'ai une application web en ASP.NET avec une base de données SQL. Pour me connecter à ma base de données, j'ai créé une chaine de connexion dans mon web.config. Jusqu'ici tout va bien, c'est après que j'ai besoin d'aide.
Dans mes différentes page j'ai besoin de me connecter à ma base de données, et je cherche la façon la plus propre, et la plus optimiser compte tenu des multiples utilisateur qui peuvent se connecter à mon site.
Solution 1:
Créer dans une classe une variable static de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public Static SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["MaChaineDeConnexion"].ConnectionString);

Ainsi quand je l'appelle pas besoin de l'instancier, mais quid de multiple utilisateurs connectés?

Solution 2:
Créer dans une classe une variable de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["MaChaineDeConnexion"].ConnectionString);

Du coup je suis obligé de l'instancier à chaque fois que j'en ai besoin. J'ai tester cette solution mais curieusement j'ai l'impression que l'accès à mes pages est beaucoup, beaucoup plus long.

Solution 3:
Créer dans chaque page où j'ai besoin de me connecter à ma base une variable de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Private SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[sMaChaineDeConnexion].ConnectionString);

et dans une classe une variable de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public const string sMaChaineDeConnexion= "MaChaineDeConnexion";

....

Ou alors il y a une solution 4 et peut être pouvez vous m'aidez ? Ou compléter mon argumentaire sur les différentes solutions.
Merci d'avance.

[François DORIN]

Bonjour,

Alors, voici des réponses

Solution 1
A éviter absolument ! Une connexion à une base de données n'est pas faite pour des accès concurrentiels. Ce qui se produira immanquablement ici, avec des bugs très difficile à reproduire car extrêmement aléatoire.

Solution 2 & 3
Elles sont équivalentes sur le principe. C'est juste la manière de la mettre en oeuvre qui diffère. Dès que tu en as besoin, tu instancies. Un "détail" très important à prendre en compte : n'oublie pas de libérer ta connexion une fois que tu n'en as plus besoin (appel à la méthode Dispose()). Cela libérera des ressources. A défaut, les connexions sont closes et libérées après un certain délai d'inactivité.

Solution 4
Une autre possibilité (dont je ne suis pas très fan perso), c'est d'utiliser une variable de session pour garder l'instance de ta connexion entre les différents appels pour un même utilisateur. Cela permet de ne faire qu'une seule instanciation, lors de la première connexion. Je ne suis pas fan de cette solution pour plusieurs raisons :

• Cela n'empêche pas les accès concurrentiels. Il faut donc protégé l'accès à la connexion via un mutex (mais contrairement à la méthode 1, les utilisateurs ne peuvent pas se bloquer entre eux) ;
• Il est difficile de détecter la déconnexion de l'utilisateur, et donc de libérer les ressources. La connexion restera généralement ouverte bien plus longtemps que nécessaire ;
• Cela occupe une connexion pendant assez longtemps pour une utilisation assez faible
• Si le pool de connexion est utilisé, cela limite le nombre d'utilisateur pouvant utiliser l'application en même temps

La création d'une nouvelle connexion est un processus assez lourd (d'où les pertes de performances que tu as pu constater entre ta solution 1 et les autres). Aussi, pour diminuer cet impact, il est possible d'utiliser le pool de connexion. Par défaut, il l'est ! Sauf si ta chaîne de connexion contient un paramètre "Pooling=false".

Comment fonctionne un pool de connexions ? A la fermeture du connexion, au lieu de fermer complètement la connexion à la base de données, la connexion est mise dans un pool et est marqué comme réutilisable (la connexion n'est pas fermée). Ainsi, lorsqu'une nouvelle connexion est nécessaire, on regarde d'abord dans le pool si une connexion est disponible et si oui, on l'utilise au lieu d'en créer une de toute pièce. Cela permet de "créer" une nouvelle connexion plus rapidement car il n'est pas nécessaire d'établir une nouvelle connexion à la base de données. La classe SqlConnection fait tout se travaille pour nous. C'est donc totalement transparent. Mais pour que cela fonctionne correctement, il est nécessaire de correctement libérer les connexions dès lors qu'on en a plus besoin (appeler la méthode Dispose()).

J'avais fais quelques tests il y a 1 an ou 2, et l'utilisation du pool de connexion accélérait d'un rapport 4 la création d'une connexion à la base de données par rapport à la version sans pool de connexion. Maintenant, l'inconvénient du pool de connexion, c'est qu'il est limité en taille. Si la taille limite est atteinte (par ex. 100 connexion) alors aucune nouvelle connexion n'est possible.

[Philace86]

Ok super pour ta réponse. Je vais également me pencher sur le pool de connexion, il se configure comment? Ca se passe au niveau de IIS?

[Dokho1000]

Tu peux aussi faire un singleton dans ta page qui ouvre une connexion vers la db et ensuite dans l'event "Unload" faire un dispose de cette façon tu n'auras qu'une connexion à la db et ca te permettra de gérer une transactions dans l'ensemble de tes usercontrols ...

A+

[DotNetMatt]

Tu peux aussi faire un singleton dans ta page

Faire un singleton ca revient a ne pouvoir servir qu'un seul utilisateur a l'instant T. Donc ca me parait plus dangereux qu'autre chose, surtout pour un site Web. A moins qu'il y ait une nuance dans ton propos que je n'ai pas saisi ?

La meilleure solution reste d'ouvrir et fermer les connexions a chaque fois (d'ou l'interet d'une DAL generique), et d'utiliser le pool de connexions. Ce dernier se debrouille mieux que n'importe qui pour les gerer.

[François DORIN]

A moins qu'il y ait une nuance dans ton propos que je n'ai pas saisi ?

Je pense que le terme singleton est effectivement mal employé. A mon avis, il s'agit de tirer profit du cycle de vie d'une page ASP.NET. Ouvrir la connexion au début, la fermer à la fin. Entre les deux, utiliser une seule et unique connexion : celle ouverte au début !

Sinon, effectivement, le singleton est une dangerosité sans nom pour gérer les connexions à la base de données, puisqu'il n'y aura alors qu'une seule connexion pour tous les utilisateurs.

La meilleure solution reste d'ouvrir et fermer les connexions a chaque fois (d'ou l'interet d'une DAL generique), et d'utiliser le pool de connexions. Ce dernier se debrouille mieux que n'importe qui pour les gerer.

[Dokho1000]

Je pense que le terme singleton est effectivement mal employé. A mon avis, il s'agit de tirer profit du cycle de vie d'une page ASP.NET. Ouvrir la connexion au début, la fermer à la fin. Entre les deux, utiliser une seule et unique connexion : celle ouverte au début !

Sinon, effectivement, le singleton est une dangerosité sans nom pour gérer les connexions à la base de données, puisqu'il n'y aura alors qu'une seule connexion pour tous les utilisateurs.

Effectivement, ce n'est pas un vrai singleton, il ne vivra que pendant le cycle de vie de la page. Mais l'idée pour mettre en place la récupération de la connexion sera pratiquement identique à un singleton.
Ici l'idée n'est pas d'avoir un objet statique mais qui sera créer en même temps que la page et "disposé" (+-) au même moment. J'utilisais beaucoup les transactions en webform et c’était le meilleur compromis a mes yeux pour ne pas garder la connexion trop longtemps tout en pouvant gérer ma transaction à travers l'ensemble de mes usercontrols.

voilà voilà

[katkiller]

Je pense que le terme singleton est effectivement mal employé. A mon avis, il s'agit de tirer profit du cycle de vie d'une page ASP.NET. Ouvrir la connexion au début, la fermer à la fin. Entre les deux, utiliser une seule et unique connexion : celle ouverte au début !

A vérifier si c'est l'idée (je vais utiliser la document de SimpleInjector pour mon explication) :

Je pense que le terme que Dokho voulait dire est "Scoped".
Et pour du web on peut dire une instance par requête