Инициализация приложения - внедрение зависимостей в DDD

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

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

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

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

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

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

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

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

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

В интернете нашел похожее обсуждение:
https://habr.com/ru/articles/493430/

... создание программы со всеми зависимости будет выглядеть следующим образом: var programm = new IndexPageController(new ProfileService(new ProfileRepository())); Согласитесь — выглядит ужасно. Даже с учетом того что в программе всего две зависимости, это уже выглядит ужасно. Что уже говорить про программы в которых сотни и тысячи зависимостей.

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

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

0

Сообщение от Shamil1 C# 1 2 3 4 5 6 7 8 public class MyStaticClass {     public static Func<IContainer> GetContainer()     {         IContainer container = new MyContainer();         return () => container;     } }

В этом коде при вызове GetContainer() каждый раз создается новый экземпляр класса MyContainer?
Так не будет работать. Ведь где-нибудь в "глубине" программы, где нужно будет создать зависимость, мы не сможем получить доступ именно к тому экземпляру-контейнеру, который был проинициализирован в Main.

Сообщение от Shamil1 ... то можно хранить словарь регистраций в файле конфигурации. Статический статический метод GetInstance<T>() на сервере будет читать конфигурацию, находить в ней целевой метод для T и создавать экземпляр через рефлексию.

Если только так.
Но хранить во внешнем файле зависимости - это мне кажется идея не очень.

0

Сообщение от zelenprog В этом коде при вызове GetContainer() каждый раз создается новый экземпляр класса MyContainer?

Да, каждый раз. Этот метод создаёт контейнер. Контейнер создаётся один раз.
Но у Вас, скорее всего, не получится с сервера на клиент передать объект типа Func<IContainer>.

Сообщение от zelenprog Но хранить во внешнем файле зависимости - это мне кажется идея не очень.

Раньше чаще делали именно так. В этом нет ничего плохого. Просто в коде обычно удобнее.

0