How to provide a plugin with data capabilities?

I have an application in which i want to provide the people who write plugins to it (plugins are made by implementing a basic interface, then i load the .dll). I want to give them the possibility to create settings and save data in my existing database. I would like to do this without having to create a table for each plugin - but if its required im willing to do it. I have come up with two basic scenarios:

1. Give the plugin an interface, where it can get a Dicti开发者_如何学Goonary and serialize it to xml and save it in my database.

2. The plugin must be contained within a .zip file with a manifest file (my own invention) where it has a create sql script and a drop script for tables.

The first has limitations towards complex data types. The second has a larger complexity in the plugin, since it needs to be within a .zip file and unpacked etc...

Please advice on either of these approaces, or alternatives.

Cheers

Your plugin constructor should recieve SettingRepository object, which provide methods for storing the setting and save them back

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

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

where PluginSettings indeed could be a dictionary, that serialized to XML

I am a little hesitant toward option 2, as you are giving a third party access to essentially write SQL directly against your database. However, option 1 seems feasible and safe. As @Euphoric said, you can use multiple keys if you need to do more complicated things.

1st aproach seems fine. If application wants to save complex configuration, it can either save it as multiple keys or serialize some complex configuration object into string.

It depends how complex the plugins are.

First approach is perfect if the pugins need only settings. In this situation I don't see any limitation of the first method. The second method does not brig anything new. You can get the same info that is in the manifest file in a datastructure and retrieve it from the plugin interface method. This is easyer because you manage only the dll file. Also if the file is very complex you can put it in a resource in the dll. In your database you can save in a table something like: plugin_name_settingname, value into a settings table that you use for all plugins.

I once had to suport a plugin mechanism where plugins nedded their own tables. In this case you can retrieve the new tabels schema and names in the interface method that plugin implenet. Then you need to create that in the database. Is like an insall for the plugin.