6
votes

In the core of our application, we use Castle Windsor to manage our dependencies. We'll be loading plugins from third parties which may be using their own IoC containers. We'd like them to be able to receive dependencies from the core, e.g. through constructor injection of the core's services, but also receive dependencies from their own IoC container.

It seems like if they supplied a service provider interface, Windsor could use it to resolve unknown dependencies, ignoring the results (since the lifetime of these components is someone else's business) and keep on trucking.

But I am also sure there are some great subtleties that come up when you attempt something like this.

1
That's a very bad idea. Mixing containers is like mixing alcohols - it never ends well.Krzysztof Kozmic
It certainly seems hangover-inducing, but surely we're not the first application which wants to use one container, but make friends with libraries which chose another.Sebastian Good
It sounds like we're trying to solve the same problem here. Read this post: stackoverflow.com/questions/6238431/common-service-registry. Did you manage to find a solution?Lawrence Wagerfield

1 Answers

6
votes

That's not necessary. If you enable those plugins to use Constructor Injection to get the appropriate services from your host application, Castle Windsor can wire up the PlugIn correctly. PlugIns simply use Constructor Injection as a way to statically declare a dependency, so as long as Windsor can resolve the dependency, the PlugIn will receive it.

What happens inside of each PlugIn (including use of other containers) is of no concern of the host application.