2015-04-25 5 views
3

Je crée un cadre pour ajouter des plugins à une application de la mienne. Chaque plugin doit implémenter une classe abstact. Chaque plugin est ensuite compilé comme une DLL que l'application principale peut trouver avec Directory.GetFiles(myPath, "*.dll")Où mettre en utilisant (SqlConnection)

Tout cela fonctionne bien et je peux instancier mes plugins dans l'application principale et les utiliser. Chaque plugin est essentiellement un widget de tableau de bord que l'utilisateur peut ajouter à son tableau de bord pour lui montrer des graphiques ou des graphiques. Cela signifie que chaque plugin dispose d'une minuterie et à chaque événement de minuteur, il rafraîchit le graphe avec les données de la base de données SQL de l'application.

Donc, ma question est, où puis-je mettre le SqlConnection? Est-ce que je crée un SqlConnection et le passe en tant que paramètre à chaque plugin ou est-ce que je passe la chaîne de connexion et ai chaque plugin crée son propre SqlConnection?

Si je passe le SqlConnection de l'application au plugin alors j'imagine que cela impliquerait une certaine gestion de la connexion dans le plugin. Je dois évidemment vérifier que c'est ouvert et que faire si l'état est ConnectionState.Fetching ou ConnectionState.Executing? Cela semble juste compliqué. Mais d'un autre côté, étant donné que plusieurs utilisateurs exécuteront l'application et que chaque utilisateur peut avoir plusieurs plugins sélectionnés dans son tableau de bord, il peut ajouter un nombre de SqlConnections. Est-ce souhaitable? Dois-je envisager une troisième option où le plugin donne sa requête à l'hôte qui la met en file d'attente avec d'autres requêtes provenant d'autres plugins et renvoie l'ensemble de résultats au plugin une fois la requête exécutée? De cette façon, il n'y a qu'un seul SqlConnection pour chaque utilisateur, quel que soit le nombre de plugins sélectionnés.

Pour être honnête, cette dernière option me semble plutôt compliquée et je ne sais pas encore comment je l'implémenterais. Si quelqu'un pouvait me diriger vers un article qui explique quelque chose de similaire, je l'apprécierais vraiment.

Répondre

4

Personnellement ce que je recommande est de passer une usine de connexion à vos plug-ins, et laissez-les créer et utiliser les connexions comme ils l'entendent. Cela signifie que votre application contrôle la chaîne de connexion (bien qu'elle puisse potentiellement encore la lire à partir de la connexion, à moins que vous ne la résumiez aussi), mais elle est libre de créer et d'utiliser des connexions si nécessaire. Comme l'a souligné une réponse précédente, si vous leur donnez simplement une connexion, il y a beaucoup de travail pour gérer les problèmes de multi-threading, et les problèmes de partage que vous avez mentionnés vous-même.

Vous pourriez faire quelque chose d'aussi simple que:

public interface ISqlConnectionFactory 
{ 
    SqlConnection GenerateConnection(); 
} 

public class SqlConnectionFactory : ISqlConnectionFactory 
{ 
    private readonly string _connectionString; 

    public SqlConnectionFactory() 
    { 
     _connectionString = "your connection string here"; 
    } 

    public SqlConnection GenerateConnection() 
    { 
     return new SqlConnection(_connectionString); 
    } 
} 

Et puis le plugin est responsable de la gestion de la connexion (par exemple l'ouverture, la fermeture, l'élimination). Il y a beaucoup plus que vous pouvez faire avec ceci pour prendre différents niveaux de contrôle sur la connexion, essayer de détecter les plugins se conduisant mal, etc.

EDIT

absoutely, vos plugins doivent utiliser l'instruction using():

public void MyPluginMain(ISqlConnectionFactory factory) 
{ 
    using(var connection = factory.GenerateConnection()) 
    { 
     // Do the work 
    } 
} 

En gardant à l'esprit que votre application se déplace le resposibility pour maintenir les connexions aux plug-ins, le plugin doit nettoyez la connexion quand c'est fait, que ce soit par l'instruction using(), ou appelez Dispose() après avoir fait ce qu'elle a fait. S'il s'agit d'une sorte d'API "publique", cela devrait faire partie de votre documentation.

+0

Merci, cela ressemble à l'approche la plus facile. Je ne suis pas familier avec "usine de connexion". Je le google maintenant, mais si vous avez un article ou quelque chose à portée de main que vous pouvez me signaler, ce serait génial. –

+0

@DewaldSwanepoel Voir mes mises à jour :) – CodingGorilla

+0

Cool bananas. Je viens de voir la mise à jour. Regarde très élégant. Je pense que c'est la voie que je vais suivre. Je ne pense pas que le plugin pourra utiliser (SqlConnection) dans ce cas? –

2

Vous ne devez pas partager la connexion entre les différents plugins, mais en créer un au sein du plugin, ou même pour chaque requête. Cela ne nuit pas aux performances, ils sont conçus pour être utilisés comme ça.

Voir SqlConnection and multithreading