.Net plugin framework choice, enabling defining plugin order (including chained plugins)

Question

[I have read previous posts on MEF vs MAF vs DI etc, they aren't helping me with my specific problem]

I am looking to write a .Net application (probably console or Windoes service) which will be extensible. It is an overnight/schedule app to extract data from a database, do something with it, and then output it (or pass it on to another system).

I am unsure what the best way to define this process for plugins. The components are:

• Task - definition of the actual task, containing plugin definitions, and event based flag on when to run (EOD,EOW,EOM)
• Source - the source of the data (a task will have one to many sources), this could be a SQL query/stored proc, web service, or perhaps a file. I see this outputting a datatable.
• PostProcess - the processing required to be done on the Source output (a task will have none to many post process steps), this could be an aggregator or some sort of specific processing). This would receive a dataset (containing the data table/s from the previous step). These would have to run in a specific order due to dependancies.
• Target - the end result (also one to many), this could be a SQL statement/stored proc, a proprietary data load, email, output file or a web service

To simplify it I would prefer that the plugins could read from the config file, this would mean I wont need to know what connection strings (and other details) to pass to plugins.

I have looked at MEF, MAF, DI, or just defining my own framework. At this stage I am leaning towards developing my own, just wondered if I had missed anything?

I would actually like to use MEF, however as I need to define my task (ie. Task links to which Sources links to which PostProcess links to which Target), and also not having access to config. I have seen MEF Primatives and Type Catalogs get me part of the way, but doesn't seem to help my chaining of plugins. Is MEF a valid choice?

Answer 1

MEF is definitely a valid choice. However, I dont think MEF was designed to be a fully fledged plug-in system, it is intended as a good starting point! MEF handles all the dirty assembly loading and disposing, but any specific pre-requisites need to checked manually. For this I would recommend using metadata. Metadata allows you to associate information with exports that can be read before you import them (MEF Metadata)

[Export(typeof(ITask))]
[ExportMetadata("Requires", "source1")]
public class Task1: ITask
{
    ...
}

Passing the config through with MEF is simple. The host application can export its self and all the plugins import it and have access to its interface. See my example below:

Interface:

public interface IMainApp
{
    ConfigClass Config { get; set; } 
}

Host App:

[Export(typeof(IMainApp))]
public class Host : IMainApp
{
    public Host()
    { /* Compose parts here..? */ }

    public ConfigClass Config { get; set; }  

    [Import(typeof(IModule))]
    public List<IModule> LoadedModules { get; set; }
}

Plug-in assembly:

[Export(typeof(IModule))]
public class Module : IModule
{        
    public Module() { }

    [Import(typeof(IMainApp))]
    public IMainApp Host { get; set; } 

    public void DoSomething()
    {
        Host.Config... // use config here
    }
}

Answer 2

It sounds like you want to do what we call explicit wireup. MEF doesn't support that by default so you would have to jump through some hoops to do so. I believe there is a config-driven programming model on MEF Contrib, which might help you.

Answer 3

You may want to take a look to Mono.Addins. You could define an extension point for each of the parts (so plugins can define new types of Sources or Targets), and then you could create an extension point for defining tasks. In the later extension point, you would define each tasks and how they relate to sources and targets.

For example, a source could be defined in a plugin like this:

[Extension (Id="MySource")]
class MySource: ISource
{
  ...
}

And the extension point for defining tasks could be like this:

<Extension path="/MyApp/Tasks">
    <Task id="someTask">
        <Source sourceId="MySource" />
        <Target targetId="MyTarget" />
    </Task>
    ...
</Extension>