IServiceProvider.GetSingleton, разрешающий нуль в Asp.Net Core DI

Question

Во время начальной загрузки моего приложения я регистрирую в основном переходные процессы и типы областей с инфраструктурой Injection Dependency, которая поставляется с .Net Core. Тем не менее, у меня есть один тип, который зарегистрирован как singleton, это мой InProcessBus (я использую архитектуру CQRS в стиле).

services.AddSingleton<InProcessBus>(new InProcessBus()); 
...   
services.AddSingleton<ICommandSender>(y => y.GetService<InProcessBus>()); 
services.AddSingleton<IEventPublisher>(y => y.GetService<InProcessBus>()); 

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

Если я проверил serviceCollection, я вижу, что реализацияFactory правильно зарегистрирована по типу под свойством ImplementationInstance.

Углубляясь и прямое разрешением типа в конце ConfigureServices() метода Startup класса утверждает, что контейнер разрешение null.

ServiceLocator.GetService<ICommandSender>() // Is Null 

Почему метод ImplementationFactory против синглтона, который явно существует в контейнере, не разрешается во время выполнения?

Answer 1

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

Короткий ответ:

Defer serviceCollection.BuildServiceProvider() к после того, как вы зарегистрировали все одноэлементные экземпляры в противном случае он не будет в состоянии решить их.

Длинный ответ:

Проблема на самом деле не имеет ничего общего с контейнером ядра жерех DI (хорошо Сорта). Проблема заключается в сроках, когда я звоню BuildServiceProvider на экземпляр serviceCollection, чтобы предоставить мне IServiceProvider.

В моей реализации я применил шаблон ServiceLocator, который обертывает фреймворк DI, который поставляется с ядром, поэтому я не вношу дополнительной зависимости в другие архитектурные слои. Когда я создаю мой IServiceContainer основанный локатор я немедленно решить ServiceProvider

public ServiceLocator(
     IServiceCollection serviceCollection) 
    { 
     _serviceCollection = serviceCollection; 
     _serviceProvider = _serviceCollection.BuildServiceProvider(); 
    } 

И здесь проблема закралась. Время, когда это ServiceProvider получить созданные явно не имеет значения для Transients и Scoped экземпляров. Но для синглтонов, имеющих управляемую продолжительность жизни, это. После всех регистраций вам необходимо отложить создание своего ServiceProviders.

С моего вопроса ServiceLocator был построен до фрагментов, что означает, что экземпляр Singleton не был бы доступен для ServiceProvider при выполнении функции implementationFactory.

Откладывая создание ServiceProvider в первый раз, мое приложение разрешает один из моих пользовательских типов во время выполнения решения проблемы.