Возможна ли перепривязка типа в DI контейнере ASP.Net Core?

Question

[Дмитрий Петров]

Суть задачи - имеется интерфейс ITest.
Для него существует реализация на основе класса TestClass1.
В методе ConfigureServices создается привязка следующим образом:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ITest, TestClass1>();
}

После запуска приложение использует экземпляр зависимости на основе TestClass1 через обращение к IServiceProvider.GetService().
Что произойдет, если во время выполнения приложения необходимо осуществить перепривязку интерфейса от типа TestClass1 к типу TestClass2, тоже реализующему интерфейс ITest? Какой подход используется в этом случае?
Как подходить к такой ситуации, если в некоторых случаях привязка singleton-объекта должна быть строгой, без возможности перепривязывания, а в некоторых допускается перепривязка.

Answer 1

[Петр]

Задайте его типом Transient и в методе фабрике возвращаете нужный инстанс обьекта

serviceCollection.AddTransient<ITest>((serviceProvider) =>
{
     return (<условие>) ? new TestClass1() : new TestClass2();
});

Comments

[Роман]

Только несколько но, условие заранее неизвестно, в коде мы не можем передать в лямбду что-то, ну и завязывать условие на глобальной статической переменной не камильфо.

[Петр]

Роман, У вас в методе фабрике доступен serviceProvider и из него вы можете получить все, что нужно. Для примера ISmtpConfiguration, где есть флаг UseSSL.
Это стандартная практика.

[Роман]

Петр, Да это понятно, у ТС`а надо менять реализацию во время работы приложения, вот в чем затык.

[Петр]

Роман, Вы застряли в своих убеждениях. )) Нет затыка. Создается менеджер, что будет хранить состояние приложения, для примера ITestManager, определяем его на singletone и он и будет опрашиваться в методе-фабрике какую реализацию предоставить.
А Transient определение не кеширует обьект и поэтому всегда будет возвращаться нужный, что создан на базе условия по значению из ITestManager

Answer 2

[Роман]

Насколько я знаю, все зависимости определяются в момент запуска и переопределить их нельзя, встроенный контейнер не даёт такой возможности.

Comments

[Дмитрий Петров]

Что делать, если подразумевается модульная структура приложения и список дополнительных сборок, загружаемых в зависимости от конфигурации, можно определить только после загрузки и инициализации львиной части зависимостей?

[Роман]

Дмитрий Петров, фабрика, и её в DI и пусть она выдает реализацию в зависимости от условий.