Concernant les meilleures pratiques pour la gestion des connexions de base de données dans une application .NET - Je sais que, en général, il est mauvais de transmettre un objet de connexion.
Cependant, j'ai des curiosités spécifiques:
Gardez une connexion statique privée ouverte et partagée, utilisée par les deux objets et laissée ouverte jusqu'à ce que le parent soit disposé.
garder deux connexions statiques privées ouvertes, une pour chaque objet, ne pas être
fermé jusqu'à ce que l'objet soit disposé.
ne conserve pas les connexions statiques; ouvert et ensuite fermer un nouveau
connexion pour chaque méthode qui le nécessite. Cependant, la plupart de mes méthodes ne gèrent que 1 à 3 requêtes, cela semble donc inefficace ...?
Gardez une connexion statique privée ouverte et partagée pour la durée de vie du formulaire.
ne conserve pas une connexion statique; Ouvrir et ensuite fermer une connexion pour chaque procédé de forme qui le requiert (à nouveau, une simple requête de 1 à 3 par procédé.)
4 Réponses :
Ma compréhension est que les connexions ne doivent rester qu'avec aussi longtemps que nécessaire. La plupart du temps, j'ai vu des connexions dans l'utilisation de déclarations similaires à
C'était aussi ma compréhension. Cependant, je suis préoccupé par les frais généraux d'ouverture constante / fermeture des connexions lorsque la moitié de mes méthodes font un travail très minime et que je me demande si une connexion unique pour une forme serait plus efficace.
@ROB: Le point d'un pool de connexion est que la vraie connexion ne sera pas ouverte et fermée. "Open" obtiendra simplement une connexion ouverte existante depuis la piscine.
Répondez aux deux questions, si vous utilisez quelque chose qui possède une mise en commun de connexion, comme Ado.net, vous devez coder vos requêtes pour que la connexion soit ouverte comme courte possible . C'est à dire. Ouvrez et fermez ensuite une nouvelle connexion pour chaque méthode qui le nécessite. . Lorsque vous fermez la connexion, il sera renvoyé sur le pool de connexion et réutilisé sur une requête ultérieure et vous n'entraînerez donc pas une pénalité de performance en ouvrant et en fermant un tas de connexions. L'avantage est que vous ne risquez pas de fuir les connexions que vous avez oublié de fermer et à long terme, vous aurez moins de connexions simultanées ouvertes que si vous gardez des connexions ouvertes pendant de longues périodes. Peu importe que l'application soit une formulaire Windows au lieu d'un formulaire Web: Gardez les connexions ouvertes aussi courtes que possible.
(était un commentaire) ...
La théorie est que vous ne devriez pas accéder à la base de votre logique métier - il devrait être dans une catégorie distincte d'accès aux données. (Dites par exemple dans l'avenir, vous devez les stocker hors ligne dans XML, ou utiliser Oracle plutôt que SQL Server ... vous ne voulez pas réécrire votre logique métier!)
Vos objets d'affaires ne devrait pas avoir des connexions de base de données qui leur sont associées. La connexion doit être ouvert dans une méthode de type usine de DAL, l'objet récupéré / intégré, la connexion est fermée et l'objet retourné.
L'entreprise eux-mêmes devraient contenir des objets champs de logique métier et les méthodes, ce qui pourrait rappeler à la couche d'accès aux données, ce qui devrait créer une nouvelle connexion de base de données pour chaque méthode DAL.
Vos craintes d'inefficacité peut être mis au repos à l'aide Pooling de connexion, ce qui signifie que si vous ouvrez et fermez une des centaines de connexion des temps, il est probable qu'ils utiliseront tout le même. Mais vous ne devriez pas garder les connexions de base de données qui traînaient du tout -. Surtout pas en tant que membres d'une classe
L'espoir qui aide!
Est-ce une application WinForm ou ASP.NET?
Voir Stackoverflow.com/questions/tagged/connection-pooling
Dupliqué possible de Connexion Plageing in .NET / SQL Server?
C'est une application Winform. En outre, compte tenu de la nature spécifique de mes questions, je ne considérerais pas cela un duplicata - ma question ne consiste pas à écrire mon propre pool de connexion, mais comment optimiser mon code en corrélation avec le pool de connexion .NET existant.
La théorie est que vous ne devriez pas accéder à la base de données de votre logique d'entreprise - il devrait être dans une classe d'accès à des données distincte. (Dites par exemple à l'avenir, vous devez les stocker hors ligne dans XML ou utiliser Oracle plutôt que SQL Server ... Vous ne voulez pas ré-écrire votre logique professionnelle!). Va faire une réponse maintenant ..
@ROB: Je pense que vous devriez lire la question que je ressentais était une duplication. La question est différente, mais les réponses y répondent réellement à votre question. Si vous ne pensez pas que cela réponde, je parie que l'une des 239 autres questions avec la même balise répondrait.
Je ne peux pas croire combien de personnes suggèrent de garder un objet de connexion autour et vivant. Ce n'est tout simplement pas raison!
@Kieren Johnstone: D'accord. @ROB: Je pense que vous devriez vraiment envisager de savoir pourquoi vos objets d'affaires savent quoi que ce soit quant à une connexion de base de données.
Kieren, John; Merci pour votre contribution. Cela a aidé beaucoup (et vous avez eu raison de répondre à l'autre fil.)