2010-12-14 78 views
0

J'ai une application dans laquelle je veux fournir les gens qui écrivent des plugins (les plugins sont créés en implémentant une interface de base, puis je charge le fichier .dll). Je veux leur donner la possibilité de créer des paramètres et enregistrer des données dans ma base de données existante. Je voudrais le faire sans avoir à créer une table pour chaque plugin - mais si c'est nécessaire je suis prêt à le faire. Je suis venu avec deux scénarios de base:Comment fournir un plugin avec des capacités de données?

  1. Donnez le plugin d'une interface, où il peut obtenir un dictionnaire et sérialisation en XML et l'enregistrer dans ma base de données. Le plugin doit être contenu dans un fichier .zip avec un fichier manifeste (ma propre invention) où il a un script create sql et un script drop pour les tables.

Le premier a des limitations concernant les types de données complexes. Le second a une plus grande complexité dans le plugin, car il doit être dans un fichier .zip et déballé etc ...

S'il vous plaît des conseils sur l'une de ces approches, ou des alternatives.

Salutations

Répondre

2

Votre constructeur de plug-in doit recevoir l'objet SettingRepository, qui fournissent des méthodes pour mémoriser le réglage et où PluginSettings pourraient en effet sauver les ramener

public MyCustomPlugin(PluginId id, SettingsRepostiory settingsRepository) 
{ 
    _id = id; 
    _settingsRepository = settings; 
} 

public void SomePluginMethod() 
{ 
    PluginSettings setting = settingsRepository.Settings.WithId(_id); 
    //... 
} 

un dictionnaire, qui sérialisé XML

+0

J'ai pensé à cette seconde après avoir posté ma réponse. Je pensais que vous pouvez mettre en œuvre quelque chose sur le modèle de IsolatedStorage sur SL, mais plus simple. – Euphoric

0

La première approche semble bien. Si l'application souhaite enregistrer une configuration complexe, elle peut l'enregistrer en tant que clés multiples ou sérialiser un objet de configuration complexe en chaîne.

1

Je suis un peu hésitant à l'égard de l'option 2, puisque vous donnez l'accès à un tiers pour écrire essentiellement du SQL directement sur votre base de données. Cependant, l'option 1 semble faisable et sûre. Comme l'a dit @Euphoric, vous pouvez utiliser plusieurs clés si vous avez besoin de faire des choses plus compliquées.

0

Cela dépend de la complexité des plugins.

La première approche est parfaite si les pugins n'ont besoin que de réglages. Dans cette situation, je ne vois aucune limitation de la première méthode. La seconde méthode ne ramène rien de nouveau. Vous pouvez obtenir la même information que celle contenue dans le fichier manifest dans une structure de données et l'extraire de la méthode de l'interface du plugin. C'est plus facile parce que vous gérez seulement le dossier de dll. Aussi, si le fichier est très complexe, vous pouvez le mettre dans une ressource dans la DLL. Dans votre base de données, vous pouvez enregistrer dans un tableau quelque chose comme: nom_plug_nom_plans, valeur dans une table de paramètres que vous utilisez pour tous les plugins.

Une fois, j'ai dû supporter un mécanisme de plugin dans lequel les plugins avaient leurs propres tables. Dans ce cas, vous pouvez récupérer le nouveau schéma tabels et les nouveaux noms dans la méthode d'interface implennet du plugin. Ensuite, vous devez créer cela dans la base de données. Est comme un insall pour le plugin.