IServiceProvider.GetSingleton在Asp.Net核心解析爲空DI

Question

在ConfigureServices()引導我的應用程序期間，我註冊了大多數瞬態和範圍類型的隨.NET Framework附帶的依賴注入框架。但是，我確實有一種類型被註冊爲單例是我的InProcessBus（我正在使用CQRS樣式的體系結構）。

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

正如你所看到的，我正在使用實現工廠函數來實現將在API控制器中使用的實際類型。真正奇怪的是，當控制器加載並且運行時嘗試構造器注入ICommandSender時，它無法解析並報告錯誤。

如果我檢查serviceCollection我可以看到，implementationFactory根據ImplementationInstance屬性下的類型正確註冊。

在Startup類ConfigureServices()方法末尾深究並直接解決類型，確認容器正在解析null。

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

爲什麼一個ImplementationFactory方法針對明確存在於容器中的單例在運行時不能解析？

Answer 1

我發現了什麼錯誤，並認爲我會在這裏發佈它，因爲它有一個重要的教訓。

簡短的回答：

推遲serviceCollection.BuildServiceProvider()到已註冊爲其他所有的單實例後，將不能夠解決這些問題。

長的答案：

這個問題實際上一點關係都沒有用asp核心DI容器（也八九不離十）。問題出在我打電話給實例上的BuildServiceProvider的時機爲我提供了一個IServiceProvider。

在我的實現中，我實現了一個ServiceLocator模式，它包裝了隨核提供的DI框架，以便在其他架構層中不引入額外的依賴關係。當我建立我的基於IServiceContainer定位器我立即解決ServiceProvider

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

而這正是問題的躡手躡腳。當ServiceProvider得到明顯創造了Transients和Scoped情況不要緊的時間。 但是對於有管理生命週期的單身人士，它確實是。在所有註冊之後，您需要推遲創建您的ServiceProviders。

從我的問題ServiceLocator是在片段之前構建的，這意味着執行implementationFactory函數時，Singleton實例不可訪問ServiceProvider。

通過推遲創建ServiceProvider到第一次，我的應用程序在運行時解決了我的一個自定義類型，解決了這個問題。