How should I be managing class dependencies/refactoring?

Question

My application implements a modular architecture that can dynamically load one or more "plugin" assemblys. Each assembly contains a class implementing an IPlugin interface, providing various methods and properties that the host app uses to interact with the plugin.

This class inevitably has dependencies on other classes within the plugin, and these may in turn have their own dependencies. So far I've been managing all this using Castle Windsor (each plugin contains an IWindsorInstaller where I register its dependencies), and doing DI via their constructors. The downside is that the classes have to be public for this approach to work.

I've now come to my senses and want to lock down the plugin by making all these classes internal, however I'm not sure of the best way to do handle the dependencies as presumably I won't be able to use Windsor. I don't want the classes to instantiate their own dependencies (not loosely-coupled, lack of testability, etc.), so what other approaches are there?

Answer 1

The downside is that the classes have to be public for this approach to work.

This is not true. You can register stuff that is internal, but you'll probably loose the auto-wiring (automatic constructor injection) feature of Castle Windsor (or any DI container for that matter). You can register internal stuff by registering delegates that create those types manually. For instance:

container.Register(Component.For<IService>()
    .UsingFactoryMethod(() =>
    {
        var log = container.Resolve<ILogger>();
        return new RealService(log);
    })
    .LifeStyle.Transient);

Manually creating services with new is suboptimal, since auto-wiring keeps the composition root of your plug in assembly the most maintainability, but I don't think there is a good alternative in your situation. Still, this is better than letting each service create its own dependencies (poor man's DI).

UPDATE

I remembered something: It should be possible to still do auto-wiring with internal types, when you register those internal types using the generic methods, such as this one:

container.Register(Component.For<IService>()
    .ImplementedBy<RealService());

For this to work, the constructor of RealService has to be public (but RealService itself can be internal). This even works in a partial trust, such as when running in the very restrictive the Silverlight sandbox (or at least, it works with Simple Injector, but Castle should be able to do this as well).

Answer 2

If you use Ninject, you can add a NinjectModule to each assembly which configures the bindings and then in the host application simply load the modules to register the bindings.

public class ServiceModule : NinjectModule
{
    public override void Load() 
    {
        Bind<IService>().To<RealService>();
    }
}

The RealService can stay internal and the module can see it because it is inside the same assembly.