I'm developing a .Net app with a modular architecture allowing it to load one or more "plugin" assemblies. Each assembly contains a class implementing an IPlugin interface which provides various methods for the hosting app to interact with the plugin.
The hosting app registers all these IPlugin classes via Windsor using the
container.Install(FromAssembly...
expression. It then instantiates the class as required to load the plugin into the main app window.
An IPlugin class will typically have dependencies on many other classes within its plugin. Currently I'm registering these with Windsor - the hosting app calls an IWindsorContainer in each plugin, allowing the plugin to register such classes. The IPlugin class's dependencies are then injected via its constructor.
Clearly this isn't a good design, as the IPlugin class shouldn't be requesting such classes (which are internal to that plugin) from a consuming application. Also, it means having to make these classes (or at least their constructors) public, otherwise they can't be registered with Windsor.
I now want to make such classes internal, but if I do this I'm not sure how the IPlugin class (which will be the only public class in the plugin) can get its dependencies. The options I can see are:-
1. Allow the class to instantiate its own dependencies, but this goes against good OO design - not loosely coupled, not testable, etc.
2. Instantiate its own dependencies using a service locator, but that's also frowned upon.
3. Continue to use Castle Windsor, ensuring that all classes are internal and with a public constructor. This feels a bit hacky, and still means my IPlugin class will have a constructor requiring all these types to be injected.
Any advice or suggestions much appreciated!
Submit an article or tip