ASP.NET/ADO.NET: Gestion de nombreuses connexions de base de données dans un objet .NET?

Question

Nous avons un objet .NET qui lit / écrit beaucoup avec la base de données. Tout au long du cycle de vie de cet objet (ou de la page asp qui l'utilise), il peut frapper la base de données avec une requête / mise à jour de 1 à 10 fois.

Au lieu d'ouvrir et de fermer une connexion de base de données chaque fois que l'objet doit atteindre la base de données, il ouvre simplement une connexion à la base de données pendant l'instanciation, puis ferme la connexion pendant l'événement de fin de l'objet. Est-ce une mauvaise pratique?

L’hypothèse était la suivante: étant donné que l’objet frappe la base de données chaque fois qu’il est instancié (et généralement plusieurs fois), il serait préférable d’ouvrir une connexion au début de la vie de l’objet, puis de la fermer à la fin.

L’autre solution consiste à ouvrir et à fermer la connexion à la base de données avant et après chaque requête / opération.

Quelle est la meilleure pratique dans ce domaine afin de maximiser les performances?

**** mise à jour **** Merci du conseil les gars. Quelqu'un peut-il parler davantage de la méthode d'ouverture / de fermeture d'une connexion à l'intérieur des événements d'instanciation / de terminaison d'un objet et de ses conséquences?

Answer 1

Ouvrez et fermez la connexion si nécessaire. ADO.NET a construit un regroupement de connexions qui fonctionne. Vous ne remarquerez aucun problème de performances, sauf si vous le faites en boucle avec des milliers d’ouvertures / fermetures.

modifier Voir Devrais-je conserver une connexion SQL dans ma couche d'accès aux données? pour plus d'informations sur les pièges de la persistance de la connexion.

Answer 2

Ouvrir et fermer à chaque fois ... Ouvrez immédiatement (le plus près possible) avant la ligne de code qui effectue réellement l'opération de base de données, et fermez dès que possible immédiatement après. Lorsque vous procédez de cette manière, ADO.net ne ferme PAS la connexion, il la libère dans le pool de connexions ADO.net, où il attend et attend la prochaine demande de connexion avec la même chaîne de connexion. Vous n’avez pas l’obligation de recréer la connexion à chaque fois ...

Le seul problème est que si vous effectuez de manière asynchrone autant de tentatives de connexion, vous dépassez le nombre maximal de connexions dans le pool ... et qu'il existe également des solutions à ce problème, à l'aide de la classe System.Threading.ThreadPool. ..

Answer 3

Pour renforcer la confiance dans l'argument de mise en pool de connexions, le fait de maintenir la connexion ouverte plus longtemps que nécessaire peut en réalité diminuer les performances globales, car le pool de connexions ne peut pas partager cette connexion avec d'autres composants nécessitant une base de données. connexion.

Alors, oui, ouvrez et fermez la connexion si nécessaire. Cependant, ce serait encore plus rapide si vous pouviez regrouper vos requêtes en un seul appel d’exec.

Answer 4

Même si ado.net ne ferme PAS la connexion, lorsque vous le faites: Conn.Close (), il exécute " sp_reset_connection " sur le serveur, même lorsque sp_reset_connection est une procédure de magasin léger, cela génère du trafic réseau. Ainsi, par exemple, je ne recommanderais pas la fermeture et l’ouverture de la connexion dans une boucle.