Plugin Architecture/Dependency Injection Question

Question

Hello,

I'm trying to figure out an architecture for plugins, but I've never worked with that. Essentially, my Program supports multiple database backends, but only one at a time.

my idea was now to create a new Assembly (".DataCore") that contains all my Repository Interfaces (IFooRepository, IBarRepository) and a IDataPlugin Interface. Then, the Plugins have to implement all those interfaces.

The user specifies the Name of the desired Assembly in the app.config file. My Program will then call a function within the DataCore Assembly which in turn uses Reflection to load the desired Assembly. Using reflection, I then search for the Class that implements IDataPlugin and call an Initialize() Function, which contains all the DI Bindings for Ninject.

So my architecture looks like:

MyProgram => new DataCoreLoader(string assemblyName) => DesiredDataPlugin.Initialize()

i'm just not sure if that is the right way, and if I should really implement this myself using reflection. I guess there are existing Frameworks? I looked at MEF briefly, but I do not know if that would help?

The reasons why I want my Plugins to have at least one discoverable class are a) I want to check a ProtocolVersion number against the one my program expects, to detect outdated plugins and b) My Configuration Tool should offer a list of all DataPlugins with some Metadata like Author or Description.

It will never be needed to load more than one Data plugin at the same time, but I'm looking for something that would allow that in other areas (In another part of the application, I want to use Plugins that subscribe to Events my Application emits).

Answer 1

That's a reasonable way to implement plugins.

Answer 2

I agree that it's a reasonable way to implement plug-ins, though it could probably be improved upon in a few ways. However, I'm not sure you need a plug-in architecture for this because .NET has one already. Take a look at DbProviderFactory.

Answer 3

If you specify desired assembly in app.config, why not specify full class name in this file? So instead of

<add key="dummy" value="DummyAssembly" />

You can write

<add key="dummyPlugin" value="DummyNamespace.DummyClass, DummyAssembly" />

Then you can instantiate you plugin using Activator class (Activator.CreateInstane)

Type DummyType = Type.GetType(DummyTypeValue);
Activator.CreateInstance(DummyType);

When you have your type you can check it for any attribute (Author, Description, Version etc), or instantiate it and check it properties before use.