Выбор и реализация оптимального механизма конфигурирования Flexberry-приложений под .net core .

[leoleopon]

Цель

Выбрать и реализовать оптимальный механизм конфигурирования Flexberry-приложений под .net core .

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

Библиотеки NewPlatform.Flexberry широко используют Unity DI для инициализации своих компонентов.
Unity DI использует файл конфигурации в формате xml. Такой же формат файла конфигурации используется log4net в составе NewPlatform.Flexberry.LogService .

В то же время приложения .net core имеют свой встроенный DI, в общем случае конфигурируемый кодом. Само приложение .net core по умолчанию конфигурируется файлом в формате json.

Необходимо определиться, один (встроенный DI либо Unity DI) или два (встроенный DI + Unity DI) следует использовать в приложениях на платформе Flexberry под .net core, а так же определиться с реализацией конфигурирования через файлы конфигурации и, соответсвенно, с номенклатурой конфигурационных файлов (один формата json либо xml, один формата json для стандартного конфигурирования .net core приложения + app.config для конфигурирования log4net и Unity DI, либо один формата json + отдельный .config для каждой подсистемы, конфигурируемой через xml.

Следует учитывать, что выбор, основанный на использовании только встроенного DI, скорее всего повлечет за собой модификацию Flexberry-библиотек, в настоящее время использующих Unity DI.

Исходный код

В качестве исследования было реализовано конфигурирование ODataService backend'а с двумя (встроенный + Unity) DI и двумя файлами конфигурации (application.json + app.config).

Указанная реализация выявила возможность неочевидного переопределения ЖЦ объекта между DI-контейнерами разных типов (в частности, инициализация экземпляра IDataService через Unity DI с ЖЦ singleton и последующее получение экземпляра IDataService через встроенный DI с ЖЦ scoped вызовом DataServiceProvider.DataService фактически для экземпляра IDataService определяет ЖЦ singleton).

[archaim]

Имхо, надо стремиться к использованию встроенного DI.

Unity-конфиг сейчас — это такая головоломка по типу кубика-рубика. Нужно убить немало часов чтобы разобраться что там есть, как настраивается и что с чем стыкуется. Это включает копание в неполной документации Unity, исходниках технологии и допросы с пристрастием ведущих и технологов.
Единственное преимущество unity-конфигов в том, что можно сборки подключать без перекомпиляции прямо сразу, но не видел чтобы этим кто-то пользовался.

Встроенный .net core di придётся использовать в любом случае, потому что это стандарт asp.net core. Его уже умеют использовать новые разработчики, которых я сейчас собеседую. Вообще, чем больше стандартных и распространённых решений — тем лучше. LogService под Core тоже надо на что-то другое перевести.

[NicholasNoise]

Для интеграции Unity DI и Core DI имеется пакет Unity.Microsoft.DependencyInjection.
Просто выбрать A или B недостаточно, нужно сравнение возможностей DI обеих библиотек. Например, Microsoft DI не поддерживает именованные регистрации, которые используется в технологии и прикладных проектах (несколько сервисов данных, несколько сервисов кэширования и тд)

Логирование я бы вынес в отдельное исследование, т.к. log4net мертв, присутствует множество альтернатив.

[archaim]

Именованные зависимости в наше время уже считаются не фичей, а плохой архитектурой ¯\(ツ)/¯

[mao29]

Считается теми, у кого не возникало задачи иметь две реализации одной зависимости в системе. Наш банальный кейс с датасервисом без использования полномочий и с использованием полномочий уже все эти мнения опровергает. Так что от я за то, чтобы оставлять юнити и искать, либо свою реализацию писать, это не так сложно

[mao29]

А чего не хватает в log4net? Из альтернатив знаю только NLog и serilog, но вопрос чем они лучше, чтобы на них имело смысл перезжать? LogService да, можно в прикладном коде не использовать, в core инфраструктура логирования есть готовая.