views:

97

answers:

2

I've written a program using Domain Driven Design in .NET 2.0 and I'm trying to implement a plugin framework for it.

I've implemented several types of plugins:

  • Domain Plugin

    • A domain aggregate composed of one or more domain classes
    • One or more View/Presenter pairs to display instances of the aggregate
    • An import/export service specific to the domain aggregate
    • A repository class
  • Service Plugins

    • Database Plugin (embedded or remote)
    • General import/export services (cvs, xml, competitor's data formats, etc)

As you can see, some plugins touch every layer of architecture. You could say that the domain plugins are miniature applications that simply depend on the main application to provide a framework in which to run. The ultimate goal is to let the user purchase and download only the plugins they need. I wrote them as static dependencies at first because I hadn't implemented a mechanism to load them dynamically. Now I'm trying to tackle the dynamic loading.

I'm trying to use an IoC container to manage the dependencies but I'm having difficulty working out how to find and load the plugins. In addition to the interfaces each plugin exposes to the main application, classes with each plugin also have their own interfaces they use to communicate with each other.

I'm using Castle Windsor as my IoC container and would like to take advantage of its autowiring capabilities both in the application and within each plugin as well.

How do I:

  1. Find and load into Windsor implementations of a specific interface
  2. Ensure Windsor resolves the correct one

If you think I'm going about this the wrong way feel free to say so. I still have time to change the design before my deadline.

+3  A: 

I'm note sure I've understood you completly but consider looking at MEF (http://mef.codeplex.com/)

Shrike
+3  A: 

You could use something like the Managed Extensibility Framework to discover and enumerate your plugins at runtime. The plugins could then register the necessary types with your IoC container when they are discovered.

GraemeF
Unfortunately MEF was built upon the .NET 3.5 and this application targets .NET 2.0. (Mostly because some of my customers are still running Windows 2000)
codeelegance
Oh sorry, I missed that.
GraemeF