Что такое рассуждение за этим IoC поведения (Resolve с несколькими зарегистрированных компонентами)

Question

Похоже стандартным подходом к МОК, когда данный сценарий как (C# Виндзор):

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

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

Был бы, что при решении компоненты , первый зарегистрированный ILogger (HttpLogger в этом случае) является единственным кандидатом на разрешение, тогда ioc найдет «самый толстый» конструктор, где он может найти, что он может разрешить все зависимости.

Однако вполне возможно, что ioc не сможет разрешить зависимости для первого регистратора и, следовательно, вернуться с проблемой разрешения, вполне возможно, что SmtpLogger COULD был разрешен, если ioc попробовал его.

Итак, в чем же причина использования только первого зарегистрированного сервиса в качестве кандидата? кажется, что неопределенность того типа, который вы получите, является аргументом, но тогда ioc остается ответственным за конструктор, который он использует в любом случае.

Так почему бы не выбрать из всех конструкторов всех применимых типов и начать пытаться разрешить от самых плохих конструкторов вниз (агностик реального типа)?

Это может иметь действительно очевидный ответ, но, честно говоря, я этого не знаю.

Заранее благодарен, Stephen.

Answer 1

Причиной этого является его влияние на сложность реализации.

Когда такое поведение реализовано, оказывается, что оно работает рекурсивно, например. выясняя, могут ли быть удовлетворены зависимости одного из регистраторов, потребуется пропустить все его зависимые от и т. д.

Чтобы сделать это эффективно, сложно, и добавляет много сложности в контейнер и опыт отладки.

MEF, хотя и не является контейнером IoC, делает это аналогично тому, что вы предложили, - это часть поведения «Стабильная композиция», что мы называем «отказом».

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

В высоко динамичном плагин сценариев, отказ является чрезвычайно полезным. В сценариях Windsor, Autofac и т. Д. Дополнительные усилия не окупаются.