Conception de l'encapsuleur de base de données C#

Question

Je suis en train de concevoir un wrapper de base de données pour C#. Voici les deux options que j'ai:

Option A:

class DBWrapper:IDisposable 
{ 
    private SqlConnection sqlConn; 

    public DBWrapper() 
    { 
      sqlConn = new SqlConnection("my connection string"); 
      sqlConn.Open(); 
    } 

    public DataTable RunQuery(string Sql) 
    { 
       implementation...... 
    } 

    public Dispose() 
    { 
      if(sqlConn != null) 
        sqlConn.Close(); 
    } 
} 

Option B:

class DBWrapper 
{ 
    public DBWrapper() 
    {    
    } 

    public DataTable RunQuery(string Sql) 
    { 
      SqlConnection sqlConn = new SqlConnection("my connection string"); 
      .....implementation...... 
      sqlConn.Close();    
    } 
} 

Pour option lorsque la classe est instancié est ouvert une connexion. Ainsi, peu importe le nombre de fois que l'appelant appelle RunQuery, la connexion est toujours prête. Mais si l'application instancie DBWrapper au début de l'application, la connexion sera simplement ouverte et ne rien faire jusqu'à ce que l'application soit terminée. En outre, il peut y avoir plusieurs DBWrapper instanciés pendant l'exécution. Donc, c'est un gaspillage de ressources.

Pour l'option B, l'option A ne l'est pas, mais une nouvelle connexion doit être ouverte et fermée chaque fois que l'appelant appelle RunQuery. Je ne suis pas sûr à quel point cela nuira à la performance.

Veuillez partager votre expertise. Merci pour la lecture.

Answer 1

Pour des raisons de performance, vous aurez certainement envie de ne pas aller avec l'option B Laissez-moi suggérer l'option C (au moins dans les cas j'ai vécu.):

class DBWrapper:IDisposable { private SqlConnection sqlConn; 

public void EnsureConnectionIsOpen() 
{ 
    if (sqlConn == null) 
    { 
     sqlConn = new SqlConnection("my connection string"); 
     sqlConn.Open(); 
    } 

} 

public DataTable RunQuery(string Sql) 
{ 
    EnsureConnectionIsOpen(); 
    implementation...... 
} 

public Dispose() 
{ 
    if(sqlConn != null) 
       sqlConn.Close(); 
} 

} 

Vous pouvez envisager d'utiliser le modèle singleton pour vous assurer qu'il n'y a qu'une seule instance de votre DBWrapper.

Answer 2

Quelques commentaires: utile d'envisager

Dans l'approche où vous gérez un (peut-être) la connexion à long terme, il est important de vérifier si la connexion est ouverte avant d'exécuter une requête. J'ai rencontré des problèmes avant où NETCF a fermé les connexions inutilisées après un certain temps. Dans l'approche où vous ouvrez une nouvelle connexion par requête, assurez-vous que votre connexion, vos commandes et (le cas échéant) les lecteurs de données sont correctement enveloppés dans des instructions ou essayez/enfin + disposez() des blocs à libérer connexions et serrures.

Bonne codification!

Answer 3

L'option B est plus transactionnelle, ce qui a ses avantages. ADO.NET utilise le regroupement de connexions implicite, vous n'avez donc pas à vous soucier de la création fréquente de nouvelles instances de SqlConnection.

Vous devez déterminer si vous utilisez un modèle de données connecté ou déconnecté; comme la deuxième approche se prête mieux à un modèle déconnecté.

Mais comme je l'ai dit plus haut, le regroupement de connexions signifie qu'il n'y a pratiquement aucune différence sur le plan pratique.

Answer 4

Vous pouvez avoir une option C où la base de données est ouverte sur demande dans RunQuery (si elle n'est pas ouverte) et fermée sur dispos (quand elle a été ouverte). De cette façon, la base de données n'est ouverte qu'en cas de besoin et ne sera ouverte qu'une seule fois.

donc dans le code pseudo:

class DBWrapper 
{ 

    public DBWrapper() 
    {    
    } 

    SqlConnection sqlConn = null; 

    public DataTable RunQuery(string Sql) 
    { 
      if(sqlConn == null) sqlConn = new SqlConnection("my connection string"); 
      .....implementation......    
    } 
    public Dispose() 
    { 
      if(sqlConn != null) 
        sqlConn.Close(); 
    } 

} 

esprit également que le moment Dispose est appelé est pas toujours directement après que l'objet n'est plus nécessaire (par exemple une variable de fonction après la fonction est utilisée).Autant que je sache, il sera exécuté quand le garbage collector recueille l'objet (ce qui n'est pas directement). Mais je ne suis pas totalement sûr de ça. Ce comportement peut également différer entre l'application Web et non Web.

Answer 5

Le garbage collector est déclenché dans des conditions plutôt complexes mais il est invoqué lorsque la mémoire dépasse une certaine limite, il est également appelé périodiquement mais la période n'est pas constante. Vous ne pouvez jamais être sûr quand exactement le garbage collector dispose et par conséquent (dans une autre course) détruit l'objet. Une chose que vous pouvez être sûr est le fait que garbage collector ne disposera et ne détruira jamais l'objet qui a encore des références. Par exemple, un objet référencé via des variables statiques sur la classe ne sera ni détruit ni détruit.