Home/ Questions/Q 346073
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T11:08:35+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0