Здравствуйте!

Подскажите как осуществляется начальная инициализация ("сборка") всех зависимостей в приложении, построенном с помощью подхода DDD?

Программа конвертирует контрагентов из старой БД в новую.
Допустим я написал весь код в виде отдельных модулей:
— код Domain-модели, который делает сопоставление старых и новых контрагентов
— код Domain-модели, который делает маппинг (непосредственно конвертация) старого контрагента в нового и вызывает запись нового в базу с помощью Репозитория
— код для используемых Repository,
— код для Вьюшек
и т.д.

В целом все сделано и все работает.

Не сделан только один момент: сейчас везде в коде используются "конкретные" реализации, там где должны использоваться интерфейсы.
Например, в Бизнес-слое при записи Сущности вызывается конкретный Репозиторий, хотя ссылка на него хранится в виде интерфейса.
Теперь нужно вынести инициализацию всех этих интерфейсов куда-то так, чтобы можно было подменить реализации.

Это нужно сделать для того, чтобы применить эту программу для конвертации другого справочника из старой БД.
Например, для конвертации товаров. Суть обработки товаров такая же как и обработка контрагентов. Отличается только часть полей.
Поэтому суть программы тоже не поменяется и останется такой же. Вьюшки на 90% не поменяются, поменяются только часть колонок в отображаемых таблицах.
Значительно поменяется только реализация маппинга и репозиториев.

Программный код реализаций для обработки товаров уже написан.
Осталось только как-то сделать "инициализацию" всего приложения, то есть "пробросить" в Бизнес-логику другую реализацию.

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

А как это делается?
По идее должна быть какая-то "центральная" точка, которая при инициализации создает конкретные объекты-реализации и передает их в Бизнес-логику.
Но ведь невозможно же заранее "знать" какие объекты могут понадобиться в программе. Получается Бизнес-логика должна сама создавать тот объект, который ей понадобится.
А как ей указать класс\тип объекта, который она должна использовать?

В интернете нашел похожее обсуждение:

... создание программы со всеми зависимости будет выглядеть следующим образом:
var programm = new IndexPageController(new ProfileService(new ProfileRepository()));

Согласитесь — выглядит ужасно. Даже с учетом того что в программе всего две зависимости, это уже выглядит ужасно. Что уже говорить про программы в которых сотни и тысячи зависимостей.

https://habr.com/ru/articles/493430/

Но там используется незнакомая мне технология.

Как правильно надо сделать?

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


Z>А как это делается?
Z>По идее должна быть какая-то "центральная" точка, которая при инициализации создает конкретные объекты-реализации и передает их в Бизнес-логику.
Z>Но ведь невозможно же заранее "знать" какие объекты могут понадобиться в программе. Получается Бизнес-логика должна сама создавать тот объект, который ей понадобится.
Z>А как ей указать класс\тип объекта, который она должна использовать?
Z>Как правильно надо сделать?

То, что Вам нужно называется Dependency Injection Container. Дальше есть 3 варианта:

1. Часть реализаций можно там зарегистрировать сразу (те, что известны заранее), часть — во время выполнения программы. Как это сделать и возможно ли — зависит от используемого контейнера.

2.Не делать динамическую регистрацию, а использовать factory class, который будет статически лежать в контейнере и возвращать нужную реализацию, например, репозитория, выбирая её в рантайме.
Это и будет та самая "центральная точка"
Так можно с любым контейнером

3. Зарегистрировать в контейнере factory method. который будет возщвращать нужный интерфейс на информации, куда-то уже сохранённой приложением.
Это тоже будет та самая "центральная точка".

V>То, что Вам нужно называется Dependency Injection Container. Дальше есть 3 варианта:

Почитал про контейнеры...

А что делать, если в "моей" платформе (среде разработки) нету контейнеров?

Можно ли написать свой класс типа "самопальный" контейнер?
Тогда получается, что каждый класс программы должен иметь ссылку на этот объект "самопального" контейнера?

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


V>>То, что Вам нужно называется Dependency Injection Container. Дальше есть 3 варианта:
Z>Почитал про контейнеры...
Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.

Z>А что делать, если в "моей" платформе (среде разработки) нету контейнеров?
Просто пишешь отдельный код сборки (wiring), создающий объекты, передающий зависимости через конструктор:

Код типа

 var programm = new IndexPageController(new ProfileService(new ProfileRepository()));

пишется, отлаживается и поддерживается гораздо проще, чем ровно то же самое, но через задни контейнер.

Z>Можно ли написать свой класс типа "самопальный" контейнер?
Не нужно.

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


Z>Почитал про контейнеры...

Z>А что делать, если в "моей" платформе (среде разработки) нету контейнеров?
Z>Можно ли написать свой класс типа "самопальный" контейнер?
Конечно, это совсем несложно. Потому их уже и написали кучу.
Простейший контейнер — это словарь, где ключ — тип интерфейса, а значение — экземпляр реализующего класса или функция его создания.
А если список типов фиксирован, а универсальность контейнера не нужна, то ещё проще, даже без словаря. Просто обычный класс или структура с полями, указывающими на текущие реализации нужных интерфейсов.

Z>Тогда получается, что каждый класс программы должен иметь ссылку на этот объект "самопального" контейнера?
каждый, где нужно его содержимое.

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


Z>>Почитал про контейнеры...
·>Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.
Вот сколько использовал контейнеры, никогда не инициализировал их через XML. КМК, это жуткое извращение.
Жутким наследием они лично мне не кажутся, у них вполне есть своя ниша, где они удобны. Тут, главное, не увлекаться и не пихать их вообще вовсюда да ещё с интерфейсами для каждого класса.
Хотя да, когда их используют индусы — иногда становится страшно, видел такое неоднократно.

Z>Можно ли написать свой класс типа "самопальный" контейнер?

Нашел вот такую статью:
https://www.wiktorzychla.com/2022/01/winforms-dependency-injection-in-net6.html

Там в качестве контейнера используется Фабрика.

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

Z>Нашел вот такую статью:
Z>https://www.wiktorzychla.com/2022/01/winforms-dependency-injection-in-net6.html

Z>Там в качестве контейнера используется Фабрика.
Это второй вариант, из тех, что я перечислял

>>Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.
XML это только в богомерзкой жаве, в C# контейнеры изначально работали без конфигов и все прекрасно.

Z>>А что делать, если в "моей" платформе (среде разработки) нету контейнеров?
·>Просто пишешь отдельный код сборки (wiring), создающий объекты, передающий зависимости через конструктор:

·>Код типа
·>

·> var programm = new IndexPageController(new ProfileService(new ProfileRepository()));
·>

·>пишется, отлаживается и поддерживается гораздо проще, чем ровно то же самое, но через задни контейнер.
Ага, очень удобно потом при добавлении новой зависимости в 50 местах прописывать ее инициализацию, вот уж где "задний контейнер"

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

V>·>Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.
V>Вот сколько использовал контейнеры, никогда не инициализировал их через XML. КМК, это жуткое извращение.
Ну не важно, детали имплементации. Главное проблема — словарь, который ошибки компиляции превращает в отложенные ошибки исполнения.

V>Жутким наследием они лично мне не кажутся, у них вполне есть своя ниша, где они удобны. Тут, главное, не увлекаться и не пихать их вообще вовсюда да ещё с интерфейсами для каждого класса.
V>Хотя да, когда их используют индусы — иногда становится страшно, видел такое неоднократно.
Какая ниша-то? Делать проджект более солидным?

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

M>Ага, очень удобно потом при добавлении новой зависимости в 50 местах прописывать ее инициализацию, вот уж где "задний контейнер"
Если это обычный код, то добавление зависимости это как добавление параметра к методу. Делается элементарно, тем более с помощью современных IDE, с проверкой корректности изменений компилятором ещё в процессе набора кода.
Контейнер все проблемы отложит на этап запуска приложения, нередко только уже в проде. А так как это просто словарь, то поведение бывает недетерминировано, и бывают такие весёлости, что даже всё работает, почти всегда.

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

V>>·>Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.
V>>Вот сколько использовал контейнеры, никогда не инициализировал их через XML. КМК, это жуткое извращение.
·>Ну не важно, детали имплементации. Главное проблема — словарь, который ошибки компиляции превращает в отложенные ошибки исполнения.
Да, есть такой недостаток. Но на практике эти ошибки довольно редки и быстро локализуются.
Тут по сути возможны всего две ошибки: попытка использования незарегистрированного объекта и попытка использовать объект с меньшим временем жизни, чем использующий.
Обе они вылетают сразу в момент создания использующего объектаэ

V>>Жутким наследием они лично мне не кажутся, у них вполне есть своя ниша, где они удобны. Тут, главное, не увлекаться и не пихать их вообще вовсюда да ещё с интерфейсами для каждого класса.
V>>Хотя да, когда их используют индусы — иногда становится страшно, видел такое неоднократно.
·>Какая ниша-то? Делать проджект более солидным?
Те проекты, где нужно отделить логику связи объектов от логики создания объектов. Как правило, это удобно, например, в типовых web проектах на ASP.NET или в проектах с бизнес-компонентами, которые друг друга используют.
Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.

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

>>>Контейнеры не нужны. Это жуткое наследие индусов в ентерпрайзе. Люди просто не могут освоить основной ЯП и думают, что если то же самое переписать на XML то случится чудо.
M>XML это только в богомерзкой жаве,
А эти C#-нутые поняли что XML — маловато будет и сделали ещё и json! Вот уж где православие и скрепы. Но это не предел! Рекомендую yaml.

M>в C# контейнеры изначально работали без конфигов и все прекрасно.
Ага, ага, ага, ну да. А думаешь откуда c# стырил идею контейнеров?

В качестве ликбеза. Все эти контейнеры пошли отсюда
https://www.youtube.com/watch?v=BcmUOmvl1N8

Приятного аппетита.

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

V>·>Ну не важно, детали имплементации. Главное проблема — словарь, который ошибки компиляции превращает в отложенные ошибки исполнения.
V>Да, есть такой недостаток. Но на практике эти ошибки довольно редки и быстро локализуются.
На моей практике — они попадают редко, но метко.

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

V>·>Какая ниша-то? Делать проджект более солидным?
V>Те проекты, где нужно отделить логику связи объектов от логики создания объектов. Как правило, это удобно, например, в типовых web проектах на ASP.NET или в проектах с бизнес-компонентами, которые друг друга используют.
wiring код это и делает. Только это обычный код на основном ЯП, а не хитрый API конкретного фреймворка.

V>Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода
Ты всё ещё не проникся. Wiring код это самый обыкновенный код, который пишется ровно так же как и весь остальной код. Скажем, дублирование можно избежать выносом одинаковых кусков в переиспользуемый метод или, например, оборачиванием в какой-нибудь цикл.
Если ты умеешь избегать дублирование кода в принципе, то это же умение точно так же работает и для wiring-кода.

V>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
Эээ... Фабрика/билдер?

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

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

V>>Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода
·>Ты всё ещё не проникся. Wiring код это самый обыкновенный код, который пишется ровно так же как и весь остальной код. Скажем, дублирование можно избежать выносом одинаковых кусков в переиспользуемый метод или, например, оборачиванием в какой-нибудь цикл.
·>Если ты умеешь избегать дублирование кода в принципе, то это же умение точно так же работает и для wiring-кода.
Я как раз проникся. Как только мы в этом wiring коде отделяем логику создания объектов с целью его переиспользования от логики их связи, мы как раз и получаем самый обыкновенный DI контейнер, разве что статический.
С семи же потенциальными проблемами рантайма(забыли создать объект, который потом пытаемся связать).
Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.

V>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
·>Эээ... Фабрика/билдер?
Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?

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

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

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

V>>>Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода
V>·>Ты всё ещё не проникся. Wiring код это самый обыкновенный код, который пишется ровно так же как и весь остальной код. Скажем, дублирование можно избежать выносом одинаковых кусков в переиспользуемый метод или, например, оборачиванием в какой-нибудь цикл.
V>·>Если ты умеешь избегать дублирование кода в принципе, то это же умение точно так же работает и для wiring-кода.
Я как раз проникся. Как только мы в этом wiring коде отделяем логику создания объектов с целью его переиспользования от логики их связи, мы как раз и получаем самый обыкновенный DI контейнер, разве что статический.
Точнее, контейнером станет набор переменных, в которых лежат созданные объекты перед тем, как их связали.
С семи же потенциальными проблемами рантайма(забыли создать объект, который потом пытаемся связать).
Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.

V>>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
V>·>Эээ... Фабрика/билдер?
Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?

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

V>>·>Верно. А в нормальном wiring коде такие ошибки просто подсвечиваются красным как ошибка компиляции ещё в процессе набора кода.
V>Это просто баланс интересов. Минимальное дублирование кода и отделение логики создания объектов ценой потенциальных ошибок в рантайме.
Дублирование ортогонально контейнеру. Можно и написать wiring код без дублирования, а можно надублировать конфигурацию контейра. Что кстати, мне нередко доводилось наблюдать — почти одинаковые конфигурации для тестов/прода; в итоге тесты работают, а прод падает, внезапно.
Никаких осязаемых преимуществ конкретно контейнер не даёт.

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

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

V>Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.
Ты видимо связывание через Property Injection? Тоже хак, который надо избегать.

V>>>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
V>>·>Эээ... Фабрика/билдер?
V>Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?
Что этот код явный и работает явно. И отлаживается как обычный код, и тестами покрывается, и стектрейсы явные и т.п.

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

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

V>>>·>Верно. А в нормальном wiring коде такие ошибки просто подсвечиваются красным как ошибка компиляции ещё в процессе набора кода.
V>>Это просто баланс интересов. Минимальное дублирование кода и отделение логики создания объектов ценой потенциальных ошибок в рантайме.
·>Дублирование ортогонально контейнеру. Можно и написать wiring код без дублирования, а можно надублировать конфигурацию контейра. Что кстати, мне нередко доводилось наблюдать — почти одинаковые конфигурации для тестов/прода; в итоге тесты работают, а прод падает, внезапно.
Вы точно не путаете проблему DI контейнера как такового с проблемой его инициализации из XML или JSON? XML/JSON это практически однозначно зло, кроме, может быть, очень редких специфичных случаев.
Если нужны одинаковые конфигурации для тестов и прода, то кто мешает слелать эту конфигурацию в одном куске кода и переиспользовать?
А если они не в одном файле, то и wiring код может отличаться.
·>Никаких осязаемых преимуществ конкретно контейнер не даёт.
В тех случаях, когда не даёт, можно ведь им не пользоваться. Я же сразу написал, что это нишевый инструмент.

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

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

ILogger myLogger = new MyCoolLogger();
IDatabase myDatabase = null;
switch (configuredDatabase) {
  case "mysql": myDatabase = new MySqlDatabase(myLogger); break;
  case "yoursql": myDatabase = new YourSqlDatabase(myLogger); break;
}

// Через 100 строчек кода

var myBusinessObject = new MyBusiness(myDatabase, myLogger);

По сути, точно такая же ошибка, как если бы забыли зарегистрировать объект в DI контейнере.


V>>Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.
·>Ты видимо связывание через Property Injection? Тоже хак, который надо избегать.
Боже упаси, конечно, нет. Я про вот это

V>>>>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
V>>>·>Эээ... Фабрика/билдер?
V>>Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?
·>Что этот код явный и работает явно. И отлаживается как обычный код, и тестами покрывается, и стектрейсы явные и т.п.
Код явный — это, конечно, хорошо. Но с таким аргументом лучше вообще библиотеками не пользоваться, а то мало ли что там внутри. Впрочем, я лично знал человека, который писал свою реализацию списка на C# толко потому, что в своей реализации он понимает, как она работает.
При отладке и содержимое контейнера прекрасно видно. А в логах — не всё ли равно какой там будет класс, свой или библиотечный?
С трейсами то же самое.
Так что на мой взгляд оно эквивалентно.

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

V>·>Дублирование ортогонально контейнеру. Можно и написать wiring код без дублирования, а можно надублировать конфигурацию контейра. Что кстати, мне нередко доводилось наблюдать — почти одинаковые конфигурации для тестов/прода; в итоге тесты работают, а прод падает, внезапно.
V>Вы точно не путаете проблему DI контейнера как такового с проблемой его инициализации из XML или JSON? XML/JSON это практически однозначно зло, кроме, может быть, очень редких специфичных случаев.
Однозначное зло — это словарь, рефлексия, строковые константы и т.п.

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

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

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

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

V>IDatabase myDatabase = null;

А причём тут wiring/контейнер?! За такой говнокод в любой части проекта надо сильно по голове бить. И переписать хотя бы вот так (или какой там синтаксис switch expression?):

ILogger myLogger = new MyCoolLogger();
IDatabase myDatabase = switch (configuredDatabase) {
  case "mysql" => new MySqlDatabase(myLogger);
  case "yoursql" => new YourSqlDatabase(myLogger);
  _ => throw new UnsupportedArgument("Unknown " + configuredDatabase);
}

И ещё сделать хотя бы enum для configuredDatabase. Строковые константы — тоже надо избегать, хотя вот как раз в DI-контейнерах без них часто никак, т.к. имена инстансов надо как-то использовать.

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

V>·>Ты видимо связывание через Property Injection? Тоже хак, который надо избегать.
V>Боже упаси, конечно, нет. Я про вот это
= null часто можно просто не писать, так что это мелкая проблема обычно.

V>·>Что этот код явный и работает явно. И отлаживается как обычный код, и тестами покрывается, и стектрейсы явные и т.п.
V>Код явный — это, конечно, хорошо. Но с таким аргументом лучше вообще библиотеками не пользоваться, а то мало ли что там внутри. Впрочем, я лично знал человека, который писал свою реализацию списка на C# толко потому, что в своей реализации он понимает, как она работает.
V>При отладке и содержимое контейнера прекрасно видно. А в логах — не всё ли равно какой там будет класс, свой или библиотечный?
V>С трейсами то же самое.
V>Так что на мой взгляд оно эквивалентно.
Так тут не надо никакой код по сути писать. Суть того, что делает контейнер, это оборачивает обычные конструкции ЯП new/if/switch в библиотечные классы.
Зачем тебе нужнен фреймворк, чтобы написать фабрику? Фабрика это просто _один_ метод, иногда даже просто лямбда.

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

V>IDatabase myDatabase = null;
V>// Через 100 строчек кода
V>var myBusinessObject = new MyBusiness(myDatabase, myLogger);
Да, кстати, IDEA в таком коде скорее всего warning покажет и какой-нибудь spotbugs заагрится. В отличие от контейнеров, где только на проде и вылезет.