Применение к ORM принципов Dependency Injection

[Anisimova2020]

Данное issue формируется на основании rfc Flexberry/rfcs#23.

Цель

Изменить ORM для корректного применения принципов DI.

Функциональные требования

1. Настройка инъекций должна производиться в одном месте.
2. Из кода ORM и ODataService требуется убрать некорректное применение паттерна DI.

Требования к реализации

Взять ПР в ОРМ #181 по Dependency Injection и попробовать:
0) обновить ветку до свежей develop-версии.

1. убрать версии ПР определение текущего пользователя (это единственное место, которое прямо явно завязано на Unity и, судя по комментариям проверяющих, это место действительно можно выпилить).
2. выпустить с ветки ПР alpha-версию 7.2 (последняя - это 7.1 в beta, там ещё будут минимальные изменения и выпуск 7.1).
3. подключить эту альфа-версию к ODataService.
4. изменить ODataService при необходимости (там есть прямые инъекции в коде местами + есть ПР Resolve IEventHandlerContainer and IFunctionContainer using dependency injection. NewPlatform.Flexberry.ORM.ODataService#51).
5. сконфигурировать тесты ODataService (там есть startup) в 3 вариантах:

• только с Unity,
• только с встроенным DI (IServiceProvider),
• с каким-то иным вариантом DI (autofac, ninject или иной, у которого реализована поддержка Microsoft...DependencyInjection). Посмотреть, какие особенности и сложности высветятся при запуске под разные фреймворки.

Потом
6) Целенаправленно по аналогии с ОРМ изменить прямые инъекции в ODataService (принять ПР Flexberry/NewPlatform.Flexberry.ORM.ODataService#51, если не сделано ранее).
7) Проверить и доделать пожелания по DI из RFC Flexberry/rfcs#23.

Вероятно, новая версия ORM будет 8.0.0, поскольку совместимость критично нарушится.

Документация

Документацию потребуется изменить, оставив только "правильные" варианты использования инъекций.

[NicholasNoise]

Пункт 5

• только с встроенным DI (IServiceProvider),

На грани невероятного для сложных приложений из-за отсутствия поддержки именованных регистраций и, как следствие, возможности построения сложного графа зависимостей.

На мой взгляд, целевым состоянием ORM должно быть container-agnostic реализация, а unity можно продолжить использовать, в конце концов оно не содержит уязвимостей и проверено временем.

[Anisimova2020]

"а unity можно продолжить использовать, в конце концов оно не содержит уязвимостей и проверено временем."

Про Unity уже шло обсуждение https://github.com/orgs/Flexberry/discussions/16 в том году.

[Anisimova2020]

Выявлено, что в зависимостях ODataService есть проект UserSettingsService
В данном проекте есть некорректное (в соответствии с правилами DI) включение зависимости : ныне CurrentUserService не существует и определение аналога интерфейса "CurrentUserService.IUser" по правилам должно быть через конструктор FlexberryUserSettingBS. Соответственно, требуется добавить получение бизнес-серверов в BusinessServerProvider через контейнер (например, IServiceProvider).
Поскольку BusinessServerProvider является по сути фабрикой, то DI позволяет туда прокидывать контейнеры.

Отсюда появилось два побочных эффекта:

1. В конструктор сервиса данных требуется передавать уже 3 параметра (3 - это корректно сформированный BusinessServerProvider с контейнером (например, IServiceProvider)).
2. Регистрация, например, в Unity такой конструкции выглядит следующим образом:

container.RegisterFactory<IBusinessServerProvider>(new Func<IUnityContainer, object>(o => new BusinessServerProvider(new UnityServiceProvider(o))), FactoryLifetime.Singleton);

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

Если побочные эффекты совсем нежелательны, то можно в FlexberryUserSettingBS вставить костыль и при Startup задавать в public static поле FlexberryUserSettingBS разрешение зависимости.

[bratchikov]

Самое главное при переработке учесть, что бизнес-сервера не должны отваливаться если программист что-то забудет. Давайте придумаем такую систему, которая будет подстраховывать программистов, когда есть BS-ы в иерархии наследования объектов данных, которые находятся в разных сборках (в разных NuGet-пакетах). Грубо говоря, если я поставляю некоторый NuGet-пакет Security.Objects в котором есть сборка с объектами и бизнес-серверами, то кто бы ни применил этот пакет - он всегда получит работающие бизнес-сервера, даже если не знает о их существовании. Надо чтобы это так и было при переходе на новый принцип DI.