Всем привет, я уже который раз попадаю в одну и

Question

Всем привет, я уже который раз попадаю в одну и

ту же ловушку абстракций, хочу попросить ваших советов.

Суть:
Есть провайдеры некой информации, интерфейс IDataProvider

interface IDataProvider
{
Task<string[]> GetDataAsync(string customer, CancelationToken? token = default);
}

Есть конкретные реализации
Например
TodoApiDataProvider

Все реализации регистрируются в контейнер с помощью рефлексии

Есть специальный TRANSIENT агрегирующий сервис, который позволяет регистрировать провайдеры. В момент регистрации провайдер резолвится из ServiceProvider и сохраняется во внутренний список, впоследствии использующийся в методе этого сервиса GetAllData(CancelationToken token).

На этом этапе все хорошо и удобно. Мы настроили 3 провайдера информации и пользуемся ими.

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

Проблема очевидна и заключается в том, что условный IDataProvider<TOptions> будет сложно регистрировать как в обычном DI (рефлексией), так и в сервисе-агрегаторе, а тем более вызывать какие-то методы из-за однотипности, когда речь идет о generic параметризации.

Поделитесь, кто и как с этим боролся/борится, пожалуйста.

Ответ "не использовать полиморфизм в таком случае" - устроит, но он слишком очевиден, хочется чего-то более изощренного