今天我先給大家出一道題：
public interface IDbContext
{
}
public class SqlServerDbContext : IDbContext
{
}
public class LongTermSerive : BackgroundService
{
private readonly IDbContext _context;
public LongTermSerive(IDbContext context)
{
_context = context;
}
protected override Task ExecuteAsync(CancellationToken stoppingToken)
{
return Task.CompletedTask;
}
}
builder.Services.AddScoped<IDbContext, SqlServerDbContext>();
builder.Services.AddHostedService<LongTermSerive>();
請問以上服務的注冊有沒有問題？
熟悉 .NET 的同學很快就會說：這當然有問題，IDbContext 是 Scope 生命周期，LongTermSerive 因為注冊成了 HostedService 所以實際上它是 Singleton 生命周期。Singleton 不能持有 Scope 生命周期的服務。說的更通用一點的話就是：生命周期長的服務無法依賴生命周期比它的服務。
真的是這樣嗎？？？
以上回答只說對了一半。這時候肯定馬上會有同學跳出來說，“這怎么會不對呢？我剛剛都試過了，VS直接報錯了”。
System.AggregateException: 'Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Microsoft.Extensions.Hosting.IHostedService Lifetime: Singleton ImplementationType: DevelopmentTest.LongTermSerive': Cannot consume scoped service 'DevelopmentTest.IDbContext' from singleton
不要著急讓我們繼續分析下去。
Captive Dependency#
首先讓我們澄清一個概念。像以上這種情況：當生命周期長(Singleton)的服務持有生命周期短(Scope)的服務的時候我們叫做 "Captive Dependency"(Transient不在討論范圍內)。
不知道怎么翻譯成中文比較合適。微軟的文檔上翻譯作"捕獲依賴"，個人認為不太恰當。
"Captive Dependency" 會帶來什么問題？
- 生命周期短的服務會被 DI 容器及時釋放，比如調用了 Dispose 方法，導致后續的操作失敗。
- 非線程安全。Singleton 的對象很容易被多個線程共享，但 Scope 的話大多數情況都是非線程安全的。比如上面的 DbContext，當在線程內共享，發生并發操作的時候程序是無法保證正確運行的。
.NET DI 支持 Captive Dependency 嗎？#
當我們了解這個概念后，上面的問題可以轉換成 " .NET DI 支持 Captive Dependency 嗎？"。
根據上一次我們的文章的內容，我們知道 .NET DI 的行為是跟所在的環境有關系的。所以討論這個問題我們還是要分開來看待：
- Development 環境下，.NET DI 會在構建 ServiceProvider 的時候去校驗服務的依賴關系。這個時候就會像上面提到的一樣，直接報錯。
- 非 Development 環境下在構建 ServiceProvider 的時候不會校驗服務間的依賴關系，程序有可能正確運行。為什么說是有可能呢？因為這個完全取決與你的代碼是怎么寫的。也許你短生命周期的服務在某些場景下正巧可以工作，又或者正巧不能工作。但是有一點是明確的，就是 Captive Dependency 是危險的。因為當你注冊成 Scope 或者 Transient 的時候往往是帶了某種暗示。比如 Scope 對象是非線程安全的。顯然 Socpe 服務的編寫者沒有義務去考慮被 Singleton 服務依賴時候的問題。
- 手動開啟
ValidateScopes = true 的時候不管什么環境下都會進行依賴關系的校驗，類似 Development 環境下。
現在我們可以作一個總結：
.NET DI 是支持 Captive Dependency 的，但是在 Development 環境下或者手動開啟 ValidateScopes = true 的時候它不支持，它會阻止 Captive Dependency。換句話說 .NET DI 在阻止 Captive Dependency 上只做了一半的工作，并不能 100% 確保不發生 Captive Dependency。開發者們在寫代碼的時候還是要自己注意了，不能完全依賴 .NET 的檢測。
關于這個問題，我也在 .NET Runtime 的 Repository 下開了一個 ticket 進行討論。微軟給出的理由是基于性能的考慮，生產環境這個校驗默認不開啟。其實我個人覺得微軟應該不管在什么環境下都默認開啟校驗，盡可能的避免 Captive Dependency。因為 90% 的項目其實并不在乎這點性能開銷。如果你的應用程序真的很在乎性能那么可以手動關閉這個校驗，這個時候開發者自己需要完全對這個依賴關系負責。
https://blog.ploeh.dk/2014/06/02/captive-dependency/
https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-guidelines#captive-dependency
https://github.com/dotnet/runtime/discussions/109491
400 186 1886
