Здравствуйте, VladD2, Вы писали:

VD>Он сам собой получается.

О как. Только что рассчет графа был главной функцией, а теперь уже сам собой.

НС>>Как ты тут зависимости определишь? Будешь IL код анализировать?
VD>Тут ты будешь этот код вручную описывать. Сначала создаешь сервис A, затем B, и затем C. И именно по этому такими DI пользоваться крайне неудобно и это прошлый век.

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

VD> Да они DI и не зовутся.

Зовется оно Microsoft.DependencyInjection

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

Именно не можешь. Нельзя ничего зарегистрировать после сборки контейнера.

VD>Вот эти вот фабричные методы "implementationFactory"

Ты опять читаешь по диагонали, теряя смысл.

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

Статический вариант уже есть, это отказ от DI.

VD> решает большинство проблем, не создавая дополнительных.

Так какую проблему решает построение графа зависимостей?

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

Приведи пример вылезшей на практике необходимости построить граф зависимостей.

НС>>Что значит показать резолвы?
VD>То и значит. 99% можно просчитывать статически.

Посчитать статически чего?

VD>Ловить циклы.

Как показывает практика, мни минимальном соблюдении несложных принципов дизайна циклы вообще не являются проблемой. Если единственное для чего нужен DI контейнер это ловить циклы, то он вообще не нужен.