Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И? Граф то зачем?

Он сам собой получается. Зависимости формально описываются направленным ациклическим графом. Если есть циклы такие зависимости уже и создать то нельзя, точнее нужно специально вместе создавать.

НС>Как ты тут зависимости определишь? Будешь IL код анализировать?

Тут ты будешь этот код вручную описывать. Сначала создаешь сервис A, затем B, и затем C. И именно по этому такими DI пользоваться крайне неудобно и это прошлый век. Да они DI и не зовутся. Такое сервис-провайдерами называют. В VS от этого, например, давно ушли и перешли на MEF.

НС>В случае штатной реализации дотнета — не может. Регистрируешь ты в IServiceCollection, а экземпляры создает IServiceProvider.

Не "не можешь", а "полностью ложится на плечи программиста". Это вообще худшее из того что можно придумать. Таким подходом пользовались на заре компонентной архитектуры. В VS 2005, например. Тут управление зависимостями полностью ложится на тебя и, как следствие, то и дело прут ошибки когда одни сервис требует другой, а тот еще не загружен. Вот эти вот фабричные методы "implementationFactory" нужны для того, чтобы отложить создание на как можно более поздний срок. Но оно все равно стреляет. И в реальности оно выливается в Ад. Проверено на тех же студийных плагинах.

Именно по этому новые поколения стали управлять созданием зависимостей. Но и это взывает проблемы, если все делается динамически. А вот статический вариант решает большинство проблем, не создавая дополнительных. Но он сложен в реализации и поддержании по тому на сегодня практически не используется.

НС>Ее и так нет.

Есть и не в теории, а постоянно на практике вылезают. Вопрос лишь в объемах кода и числе разработчиков работающих над проектом.

НС>Что значит показать резолвы?

То и значит. 99% можно просчитывать статически. Ловить циклы. Показывать тот самый DAG зависимостей явно и ходить по нему. Математика вместо динамики.