views:

72

answers:

1

Seems like a standard approach for an ioc when given a scenario like (C# windsor):

container.AddComponent<ILogger, HttpLogger>();
container.AddComponent<ILogger, SmtpLogger>();

var logger = container.Resolve<ILogger>();

Would be that when resolving the component, the first registered ILogger (HttpLogger in this case) is the only candidate for resolution, the ioc will then find the 'fattest' constructor it can where it believes it can resolve all the dependencies.

However, it may well be the ioc cannot resolve the dependencies for the first logger, and will thusly return with a resolution issue, it could well be the case that the SmtpLogger COULD have been resolved if the ioc tried it.

So what is the reasoning for only using the first registered service as the candidate? it seems that the uncertainty of which type you will get is an argument, but then the ioc is being left in charge of which constructor that it uses anyway.

So why not pick from all the constructors of all applicable types, and start trying to resolve from the fattest constructors down (agnostic of the real type)?

This may have a really obvious answer but honestly I don't know it.

Thanks in advance, Stephen.

+2  A: 

The reason for this is its effect on implementation complexity.

When this kind of behaviour is implemented, it turns out to work recursively, e.g. figuring out whether the dependencies of one of the loggers can be satisfied will require a walk down all of its dependencies and so on.

To do this efficiently is hard, and adds a lot of complexity to the container and to the debugging experience.

MEF, while not strictly an IoC container, does do this in a way similar to what you've suggested - it is part of the Stable Composition behaviour, something we refer to as 'rejection'.

http://blogs.msdn.com/nblumhardt/archive/2009/07/17/light-up-or-mef-optional-exports.aspx

In highly-dynamic plug-in scenarios, rejection is extremely useful. In the scenarios Windsor, Autofac etc are targeting, the added effort doesn't pay off so much.

Nicholas Blumhardt
Ah ha! well I was starting to think I wouldn't get an answer, then I get an answer from an ioc master :), thanks a lot!
meandmycode
Also, you want to fail fast. If you changed someting that makes first component impossible to resolve you want to know it immediatelly, not after a crash at client site happens and you get angry call, that they were down for 2 hours without anyone noticing, because now IHttpLogger was injected instead of ISMSLogger
Krzysztof Koźmic
I understand, although similar to how I'm assuming MEF handles this, I would argue to have a resolution method that returned resolution details and not just the service instance, and potentially logging resolution issues in a more cross cutting fashion.
meandmycode