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

V>>Если нужны одинаковые конфигурации для тестов и прода, то кто мешает слелать эту конфигурацию в одном куске кода и переиспользовать?
·>В этом случае придётся бороться с фреймворком как вменяемо разделять конфигурации.
В любом случае эта проблема не зависит от наличия или отсутствия DI

V>>·>Никаких осязаемых преимуществ конкретно контейнер не даёт.
V>>В тех случаях, когда не даёт, можно ведь им не пользоваться. Я же сразу написал, что это нишевый инструмент.
·>Так мой поинт, что никогда не даёт.
Так вы же сами рассматриваете контейнер как вариант реализации, если нужно выносить общую логику создания объектов либо делать разные управляемые времена жизни.
Вся разница в том, что Вы для этого не хотите использовать готовые обобщённые реализации.

V>>·>Ну можно так выразиться, хотя неясно почему "контейнер", нет ничего контейнерного (словаря-то нет!). Это и есть хорошо, что статический. Динамика это в php и javascript, зачем это тащить в компилируемые ЯП — неясно.
V>>Словарь — это всего лишь один из возможных механизмов реализации. Если контейнер не будет библиотекой для использования в произвольных проектах, а делается для одного раза, то словарь будет только лишним.
·>А какие другие возможные механизмы? Нужна коллекция объектов, граф типов зависимостей и т.п. Это и есть контейнер.
Как я писал уже в ответе ТС, простейший вариант — это тупо класс с полями, в которых либо сами реализации объектов, либо их factory functions.

V>>·>Подавляющее большинство связывания будет через Constructor Injection. Т.е. ты тупо не сможешь создать объект в коде не имея нужных ему зависимостей.
V>>Пример:
·>

V>>IDatabase myDatabase = null;
·>

·>А причём тут wiring/контейнер?! За такой говнокод в любой части проекта надо сильно по голове бить. И переписать хотя бы вот так (или какой там синтаксис switch expression?):
Это код просто для иллюстрации проблемы. Я сам прекрасно вижу его косяки.
Это упрощённый вариант для объяснения того, что где-то в создании объектов может быть ошибка, которую всё равно не отловит компилятор.

V>>По сути, точно такая же ошибка, как если бы забыли зарегистрировать объект в DI контейнере.
·>Такая ошибка может быть в любом коде. Wiring тут не при чём.
Именно это я и хотел продемонстрировать. Эта ошибка может быть и в wiring коде и в регистрации объектов в контейнере, поэтому с этой точки зрения без разницы, использовать контейнер или нет.

·>Так тут не надо никакой код по сути писать. Суть того, что делает контейнер, это оборачивает обычные конструкции ЯП new/if/switch в библиотечные классы.
·>Зачем тебе нужнен фреймворк, чтобы написать фабрику? Фабрика это просто _один_ метод, иногда даже просто лямбда.
Чтобы написать — не нужен. А чтобы хранить ссылку на эту фабрику для её использования из разных мест нужен либо библиотечный контейнер либо самописный.
По сути контейнер есть ни что иное как глобальная переменная. Весь вопрос в её типизации и формате использования.
Если хотите её использовать в стиле "дай мне ссылку на текущюю реализацию базы данных" — тогда можно использовать просто свой класс. Плюс — наличие переменной проверяется компилятором, в простых случаях проверяется и её инициализация.
Если хотите её использовать в стиле "дай мне ссылку на реализацию интерфейса IБазаДанных" — тогда удобнее использовать словарь или библиотечный контейнер. Плюс — проще реализовать различные времена жизни.
Если писать свою программу без всяких фреймворков, то это просто вопрос личных предпочтений.
Если в рамках готового фреймворка, который уже основан на DI, то разумно этот стиль и поддерживать.