戰(zhàn)：生命周期、作用域與高級(jí)玩法)
1. 為什么說(shuō)依賴注入是 ASP.NET Core 的“地基”我第一次接觸 ASP.NET Core 的時(shí)候最直觀的感受就是這和舊的 .NET Framework 時(shí)代寫代碼的方式完全不一樣了。以前在 ASP.NET MVC 5 里想要在控制器里用一個(gè)服務(wù)通常就是new一個(gè)出來(lái)或者借助某個(gè)靜態(tài)類、某個(gè)單例工廠去拿。那時(shí)候項(xiàng)目里的服務(wù)之間互相 new、互相依賴代碼耦合得像一團(tuán)亂麻測(cè)試更是難以下手。而 ASP.NET Core 從出生那天起就把依賴注入DI做進(jìn)了框架的骨髓里。你看到的Startup類里的ConfigureServices方法、控制器構(gòu)造函數(shù)里直接聲明接口參數(shù)、中間件里通過(guò)RequestServices獲取服務(wù)這些都是依賴注入在背后起作用?？梢哉f(shuō)不搞懂依賴注入你根本沒(méi)法理解 ASP.NET Core 的應(yīng)用是怎么被組裝起來(lái)的。那依賴注入到底解決了什么問(wèn)題我用一句話概括它把“創(chuàng)建依賴”這件事從你手里拿走交給你注冊(cè)的容器統(tǒng)一管理。比如你的業(yè)務(wù)服務(wù)OrderService依賴一個(gè)IOrderRepository傳統(tǒng)寫法里你必須在OrderService內(nèi)部親手new一個(gè)具體的SqlOrderRepository。一旦換了數(shù)據(jù)庫(kù)、換了實(shí)現(xiàn)方式你得跑到每一處new的地方去改。而依賴注入的做法是OrderService只需要在構(gòu)造函數(shù)里聲明“我需要一個(gè)IOrderRepository”至于這個(gè)接口到底由哪個(gè)類來(lái)實(shí)現(xiàn)、生命周期是多久全部交給容器在注冊(cè)時(shí)決定。這不只是“解耦”兩個(gè)字那么簡(jiǎn)單。它直接改變了你組織代碼的方式。以前你寫代碼的粒度通常是“類”而現(xiàn)在你會(huì)下意識(shí)地按照“接口 實(shí)現(xiàn) 注冊(cè)”的方式來(lái)組織。你會(huì)更自然地拆出小服務(wù)、小組件每個(gè)組件只干一件事組件之間通過(guò)接口通信。這種代碼風(fēng)格一旦形成習(xí)慣項(xiàng)目的可維護(hù)性會(huì)肉眼可見地提升。我在帶團(tuán)隊(duì)的時(shí)候經(jīng)常說(shuō)依賴注入不只是一個(gè)框架功能它是一套編碼思維。你理解了它再看 ASP.NET Core 的管道、中間件、配置系統(tǒng)、日志系統(tǒng)都會(huì)覺得處處相通因?yàn)檫@些底層機(jī)制全都建立在 DI 容器之上。反過(guò)來(lái)如果你只是照著模板抄代碼碰到“在構(gòu)造函數(shù)里注入某個(gè)服務(wù)”的寫法也只會(huì)在用到的時(shí)候照貓畫虎一旦遇到循環(huán)依賴、生命周期沖突這種疑難雜癥就會(huì)一臉懵。所以這篇文章我想把自己在實(shí)際項(xiàng)目里折騰依賴注入的經(jīng)驗(yàn)整理出來(lái)。從核心概念、生命周期到實(shí)戰(zhàn)中繞不開的高級(jí)玩法比如工廠模式、裝飾器模式、Scope 驗(yàn)證再到踩過(guò)的坑和調(diào)試技巧爭(zhēng)取講得既有原理又有干貨。不管你是剛接觸 ASP.NET Core 的新手還是寫著寫著總覺得哪里不對(duì)勁的老手應(yīng)該都能從里面找到一些有價(jià)值的東西。2. 從IServiceProvider說(shuō)起容器到底替我們做了什么很多人上來(lái)就背“構(gòu)造函數(shù)注入”“AddScoped”“AddTransient”但這些概念背熟以后腦子里依然是一團(tuán)漿糊。我的建議是先弄懂最底層的那個(gè)對(duì)象——IServiceProvider。在 ASP.NET Core 里整個(gè)應(yīng)用其實(shí)就是一個(gè)“服務(wù)集合”的組裝結(jié)果。你寫builder.Services.AddXxx()的時(shí)候本質(zhì)上是在往一個(gè)ServiceCollection里添加服務(wù)描述。這個(gè)ServiceCollection就像一張菜單列著“什么接口對(duì)應(yīng)什么實(shí)現(xiàn)以什么生命周期來(lái)創(chuàng)建”。等到應(yīng)用啟動(dòng)框架根據(jù)這張菜單構(gòu)建出一個(gè)IServiceProvider實(shí)例也就是真正的“服務(wù)容器”。IServiceProvider的核心只有一個(gè)方法object GetService(Type serviceType)。你告訴它你想要什么類型它就根據(jù)之前注冊(cè)的規(guī)則幫你把這個(gè)類型以及它依賴的東西完整地實(shí)例化出來(lái)。聽起來(lái)簡(jiǎn)單但這背后牽扯出幾個(gè)關(guān)鍵問(wèn)題構(gòu)造函數(shù)里要的參數(shù)怎么來(lái)同一個(gè)服務(wù)被請(qǐng)求多次時(shí)是返回同一個(gè)實(shí)例還是每次都新建如果服務(wù)之間有循環(huán)依賴怎么處理我用一個(gè)生活里的類比來(lái)解釋服務(wù)容器就像一個(gè)全能中介。你要租房子解析IOrderRepository中介會(huì)根據(jù)你的需求去匹配房東具體實(shí)現(xiàn)類SqlOrderRepository。如果房子需要配家具構(gòu)造函數(shù)依賴DbContext中介還會(huì)順手聯(lián)系家具商解析DbContext把家具也安排到位。你只需要告訴中介“我要什么”剩下的一堆復(fù)雜流程都不用管。實(shí)際寫代碼的時(shí)候最常用的入口有四個(gè)IServiceProvider直接獲取服務(wù)實(shí)例IServiceScopeFactory創(chuàng)建子作用域IServiceScope作用域本身ActivatorUtilities在容器之外輔助創(chuàng)建對(duì)象同時(shí)盡量解析其依賴其中IServiceScopeFactory是很多人一開始容易忽略的。在后臺(tái)任務(wù)、控制臺(tái)應(yīng)用、或者某些需要“手動(dòng)解析服務(wù)”的場(chǎng)景里你往往會(huì)用serviceProvider.CreateScope()創(chuàng)建一個(gè)作用域來(lái)拿服務(wù)。如果不這么做直接拿IServiceProvider.GetService(typeof(MyService))去解析一個(gè) Scoped 服務(wù)大概率會(huì)得到一個(gè)異?；蛘吣玫揭粋€(gè)不按預(yù)期生命周期工作的實(shí)例。關(guān)于這點(diǎn)我踩過(guò)比較經(jīng)典的坑是在 ASP.NET Core 的 Startup 階段嘗試解析 Scoped 服務(wù)。比如有人想在Configure方法里通過(guò)app.ApplicationServices.GetServiceMyDbContext()直接拿數(shù)據(jù)庫(kù)上下文去初始化數(shù)據(jù)。運(yùn)行起來(lái)會(huì)發(fā)現(xiàn)這種方式在某些版本里能拿到對(duì)象但 DbContext 的跟蹤行為、連接管理并不符合預(yù)期甚至可能因?yàn)樽饔糜蛉笔?dǎo)致連接沒(méi)有及時(shí)釋放。正確做法是手動(dòng)創(chuàng)建一個(gè) Scope在這個(gè) Scope 里拿 DbContext 用用完釋放。這個(gè)細(xì)節(jié)我在后面的生命周期章節(jié)里還會(huì)重點(diǎn)展開。理解了IServiceProvider你就抓住了 DI 容器的“心臟”。后面聊生命周期、聊擴(kuò)展點(diǎn)都是圍繞這個(gè)核心展開的。3. 生命周期三兄弟Transient、Scoped、Singleton 到底怎么選ASP.NET Core 的 DI 容器支持三種生命周期模式這恐怕是日常開發(fā)里討論最多、也最容易出問(wèn)題的地方。先說(shuō)定義再說(shuō)我的理解最后講實(shí)操選擇。生命周期創(chuàng)建時(shí)機(jī)特點(diǎn)典型場(chǎng)景Transient瞬態(tài)每次從容器解析時(shí)都新建實(shí)例最輕、無(wú)狀態(tài)輕量工具類、無(wú)狀態(tài)服務(wù)Scoped作用域每個(gè)作用域內(nèi)只創(chuàng)建一個(gè)實(shí)例一個(gè)請(qǐng)求一個(gè)實(shí)例DbContext、業(yè)務(wù)服務(wù)Singleton單例整個(gè)應(yīng)用生命周期內(nèi)只有一個(gè)實(shí)例全局共享緩存、配置、日志提供者定義大家都懂但實(shí)際選擇時(shí)經(jīng)常有爭(zhēng)議。我覺得關(guān)鍵要把握兩條原則有沒(méi)有狀態(tài)狀態(tài)的生命周期應(yīng)該有多長(zhǎng)Singleton適合“無(wú)狀態(tài)或有意共享狀態(tài)”的服務(wù)。比如一個(gè)MemoryCache包裝類全局只有一個(gè)實(shí)例里面的數(shù)據(jù)在所有請(qǐng)求之間共享這很合理。但如果你把一個(gè)有狀態(tài)的類比如包含可變字段的服務(wù)注冊(cè)成 Singleton就要警惕多線程并發(fā)問(wèn)題。多個(gè)請(qǐng)求同時(shí)讀寫同一個(gè)實(shí)例的字段輕則數(shù)據(jù)錯(cuò)亂重則出現(xiàn)難以復(fù)現(xiàn)的 bug。Scoped適合“一個(gè)請(qǐng)求內(nèi)保持一致”的服務(wù)。最典型的就是DbContext。一個(gè) HTTP 請(qǐng)求里你可能會(huì)在多個(gè)地方使用數(shù)據(jù)庫(kù)上下文如果每個(gè)地方都拿到不同的 DbContext 實(shí)例那么它們各自跟蹤不同的實(shí)體狀態(tài)事務(wù)和性能都是災(zāi)難。Scoped 保證同一個(gè)請(qǐng)求范圍內(nèi)拿到的都是同一個(gè)實(shí)例這個(gè)問(wèn)題就自然解決了。Transient適合“每次使用都獨(dú)立”的服務(wù)。比如一個(gè)EmailValidator它內(nèi)部只保存驗(yàn)證規(guī)則不保存用戶狀態(tài)每次新建一個(gè)實(shí)例成本很低也無(wú)所謂共享。再比如有些服務(wù)內(nèi)部依賴了另一個(gè) Transient 服務(wù)每次解析都需要一個(gè)干凈的組合那么 Transient 就是合適的選擇。但實(shí)際項(xiàng)目里經(jīng)常出現(xiàn)“看似無(wú)狀態(tài)其實(shí)有隱含狀態(tài)”的服務(wù)這是最坑的。我舉一個(gè)例子你寫了一個(gè)AuditLogger構(gòu)造函數(shù)里注入了一個(gè)IHttpContextAccessor用來(lái)記錄當(dāng)前請(qǐng)求的用戶信息。表面上看它沒(méi)有字段、沒(méi)有狀態(tài)非常適合注冊(cè)成 Singleton。但I(xiàn)HttpContextAccessor本身是 Scoped 的它的內(nèi)部邏輯依賴請(qǐng)求上下文如果你把AuditLogger注冊(cè)成 Singleton而它又注入了 Scoped 的IHttpContextAccessor這時(shí)候容器就會(huì)拋異常。為什么因?yàn)?Singleton 的實(shí)例在應(yīng)用啟動(dòng)時(shí)就創(chuàng)建了它不像請(qǐng)求那樣有明確的生命周期邊界。如果允許一個(gè) Singleton 持有 Scoped 服務(wù)的引用那么這個(gè) Scoped 服務(wù)到底是哪個(gè)請(qǐng)求的容器沒(méi)法回答這個(gè)問(wèn)題所以干脆在注冊(cè)時(shí)就不允許這種依賴關(guān)系。這就是著名的“生命周期捕獲”問(wèn)題是 ASP.NET Core DI 新手最容易踩的大坑之一。我也碰到過(guò)這種情況一個(gè)實(shí)現(xiàn)類被同時(shí)注冊(cè)成了 Scoped 和 Singleton 兩種方式代碼里有些地方用的是 Scoped 的解析有些地方用的是 Singleton 的解析。結(jié)果是同一個(gè)邏輯在某些請(qǐng)求里共享狀態(tài)在某些請(qǐng)求里又各自獨(dú)立排查問(wèn)題的時(shí)候讓人非常抓狂。我后來(lái)給自己定了一條規(guī)矩同一個(gè)服務(wù)類型在整個(gè)容器中只注冊(cè)一種生命周期除非有極其特殊的需求否則絕不在多個(gè)地方用不同生命周期重復(fù)注冊(cè)。4. Scope 與請(qǐng)求管道為什么你的服務(wù)在一個(gè)“虛擬邊界”里工作前面反復(fù)提到“作用域Scope”這個(gè)詞對(duì)新手來(lái)說(shuō)有點(diǎn)抽象。我盡量用最直白的方式拆開講。其實(shí) Scope 就是容器創(chuàng)建的一組服務(wù)實(shí)例的“集合邊界”。在 ASP.NET Core 的請(qǐng)求管道里框架會(huì)在每個(gè) HTTP 請(qǐng)求開始時(shí)自動(dòng)創(chuàng)建一個(gè) Scope并在請(qǐng)求結(jié)束時(shí)把它釋放。這個(gè) Scope 里解析的所有 Scoped 服務(wù)生命周期都跟這一個(gè)請(qǐng)求綁定。請(qǐng)求開始服務(wù)創(chuàng)建請(qǐng)求結(jié)束服務(wù)釋放。整個(gè)過(guò)程你基本不需要手動(dòng)干預(yù)框架已經(jīng)幫你處理好了。但這個(gè)“自動(dòng)”背后有一個(gè)重要前提你的代碼必須沿著請(qǐng)求管道走。如果你的代碼是在請(qǐng)求之外的上下文里執(zhí)行比如后臺(tái)托管服務(wù)、定時(shí)任務(wù)、消息隊(duì)列消費(fèi)者那就沒(méi)有現(xiàn)成的 Scope 可用。這時(shí)候如果你直接解析 Scoped 服務(wù)就會(huì)遇到我前面說(shuō)的麻煩。我舉個(gè)例子。假定你寫了一個(gè)IHostedService在應(yīng)用啟動(dòng)后每 30 秒執(zhí)行一次數(shù)據(jù)清理任務(wù)。任務(wù)里要用到MyDbContextScoped如果你直接注入MyDbContext到后臺(tái)服務(wù)構(gòu)造函數(shù)里應(yīng)用啟動(dòng)時(shí)容器就會(huì)報(bào)錯(cuò)因?yàn)镮HostedService本身是 Singleton 的它不能依賴 Scoped 服務(wù)。解決方式是在后臺(tái)任務(wù)的每次執(zhí)行中手動(dòng)創(chuàng)建 Scopepublic class CleanupHostedService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; public CleanupHostedService(IServiceScopeFactory scopeFactory) { _scopeFactory scopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using (var scope _scopeFactory.CreateScope()) { var dbContext scope.ServiceProvider.GetRequiredServiceMyDbContext(); // 執(zhí)行清理邏輯 } await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken); } } }這里的關(guān)鍵是IServiceScopeFactory本身是 Singleton 安全的你可以放心地把它注入到任何地方。每次要干活的時(shí)候用CreateScope()開一個(gè)新的“小容器”在這個(gè)小容器里解析 Scoped 服務(wù)用完立刻釋放。這樣既遵守了生命周期規(guī)則又不會(huì)出現(xiàn)“Singleton 依賴 Scoped”的沖突。我在實(shí)際項(xiàng)目里把這個(gè)模式用得非常頻繁尤其是寫后臺(tái)任務(wù)、定時(shí)任務(wù)、消息隊(duì)列消費(fèi)者的時(shí)候?？梢赃@么理解凡是離開了 HTTP 請(qǐng)求管道、又需要解析 Scoped 服務(wù)的場(chǎng)景都要養(yǎng)成“手動(dòng)開 Scope”的習(xí)慣。這不是可選項(xiàng)是必須項(xiàng)否則你拿到的要么是異常要么是行為詭異的服務(wù)實(shí)例。還有一個(gè)容易被忽略的場(chǎng)景你在中間件里拿服務(wù)。中間件本身是在請(qǐng)求管道里的所以它默認(rèn)就有 Scope 的上下文。但如果你用RequestServices.GetService()和直接用構(gòu)造函數(shù)注入結(jié)果是不太一樣的。構(gòu)造函數(shù)注入的中間件實(shí)例是 Singleton 創(chuàng)建的它拿不到當(dāng)前請(qǐng)求的 Scope 服務(wù)而通過(guò)RequestServices拿服務(wù)是在當(dāng)前請(qǐng)求的 Scope 里拿的這才是正確姿勢(shì)。我的經(jīng)驗(yàn)是中間件里如果需要依賴 Scoped 服務(wù)優(yōu)先用RequestServices不要指望構(gòu)造函數(shù)注入。構(gòu)造函數(shù)注入適合 Scoped 服務(wù)那種“每個(gè)請(qǐng)求都不同”的場(chǎng)合但中間件只有一個(gè)實(shí)例所以它沒(méi)法持有請(qǐng)求級(jí)別的服務(wù)引用。5. 實(shí)戰(zhàn)技巧工廠模式、裝飾器模式與條件注冊(cè)聊完生命周期我想分享幾個(gè)實(shí)際項(xiàng)目中經(jīng)常用到的高級(jí)玩法。這些玩法不是 AspNet Core DI 的“必學(xué)操作”但如果你經(jīng)歷過(guò)某個(gè)痛點(diǎn)就會(huì)知道它們有多香。5.1 工廠模式同一個(gè)接口多個(gè)實(shí)現(xiàn)怎么處理一個(gè)接口多個(gè)實(shí)現(xiàn)類是 DI 里最直接的挑戰(zhàn)。最常見的是接口IPaymentGateway有支付寶實(shí)現(xiàn)、微信支付實(shí)現(xiàn)、銀聯(lián)實(shí)現(xiàn)你想在運(yùn)行時(shí)根據(jù)上下文選擇具體用哪個(gè)。最笨的辦法是把所有實(shí)現(xiàn)都注冊(cè)上去然后靠IEnumerableIPaymentGateway注入進(jìn)來(lái)自己循環(huán)判斷。但這樣代碼會(huì)越寫越亂。更優(yōu)雅的方案是注冊(cè)一個(gè)工廠委托services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var providerName config[Payment:Provider]; switch (providerName) { case Alipay: return new AlipayGateway(...); case WeChat: return new WeChatGateway(...); default: throw new InvalidOperationException($Unknown provider: {providerName}); } });工廠委托的優(yōu)勢(shì)是你可以在創(chuàng)建服務(wù)時(shí)做復(fù)雜的初始化、根據(jù)配置選擇實(shí)現(xiàn)類、或者做延遲初始化。所以當(dāng)你發(fā)現(xiàn)某個(gè)服務(wù)的構(gòu)造過(guò)程不只是一句new Xxx(params...)的時(shí)候就該考慮用工廠注冊(cè)來(lái)代替默認(rèn)的反射構(gòu)造。5.2 裝飾器模式在不改原代碼的情況下增加橫切邏輯裝飾器模式是 DI 里用來(lái)做“橫切關(guān)注點(diǎn)”的利器。什么叫橫切關(guān)注點(diǎn)比如日志、緩存、性能監(jiān)控、故障恢復(fù)這些邏輯縱向貫穿業(yè)務(wù)代碼把它寫在業(yè)務(wù)服務(wù)內(nèi)部會(huì)讓代碼很臟。舉個(gè)例子。你有一個(gè)IWeatherService里面提供了GetWeatherAsync。你不想改動(dòng)WeatherService本身但想在每次調(diào)用時(shí)記錄耗時(shí)、加緩存、做重試。這時(shí)候你寫一個(gè)LoggingWeatherService它實(shí)現(xiàn)同一個(gè)接口內(nèi)部包裝一個(gè)真實(shí)的IWeatherServicepublic class LoggingWeatherService : IWeatherService { private readonly IWeatherService _inner; private readonly ILoggerLoggingWeatherService _logger; public LoggingWeatherService(IWeatherService inner, ILoggerLoggingWeatherService logger) { _inner inner; _logger logger; } public async TaskWeatherResult GetWeatherAsync(string city) { var sw Stopwatch.StartNew(); try { return await _inner.GetWeatherAsync(city); } finally { _logger.LogInformation(GetWeatherAsync took {Elapsed}ms, sw.ElapsedMilliseconds); } } }注冊(cè)的時(shí)候稍微繞一下services.AddTransientWeatherService(); // 真實(shí)實(shí)現(xiàn) services.AddTransientIWeatherService(sp new LoggingWeatherService(sp.GetRequiredServiceWeatherService(), sp.GetRequiredServiceILoggerLoggingWeatherService()));雖然代碼看起來(lái)多了一點(diǎn)點(diǎn)但好處是業(yè)務(wù)邏輯類根本不知道日志的存在日志邏輯獨(dú)立成一個(gè)類可復(fù)用、可測(cè)試。如果你用 Scrutor 這類庫(kù)還能自動(dòng)掃描程序集批量給所有實(shí)現(xiàn)了某個(gè)接口的類套上裝飾器省去大量手工注冊(cè)代碼。我在項(xiàng)目里用裝飾器做過(guò)緩存、重試、審計(jì)、分布式鎖等橫切能力效果非常棒。它和 AOP面向切面編程的思想一致但在 .NET 世界里不需要引入復(fù)雜的 AOP 框架用 DI 原生的方式就能實(shí)現(xiàn)。5.3 條件注冊(cè)根據(jù)運(yùn)行時(shí)配置決定要不要注冊(cè)某個(gè)服務(wù)依賴注入的條件注冊(cè)不一定要用第三方庫(kù)簡(jiǎn)單的判斷完全可以在ConfigureServices里完成if (environment.IsDevelopment()) { services.AddScopedINotificationSender, FakeNotificationSender(); } else { services.AddScopedINotificationSender, EmailNotificationSender(); }這種寫法最常見于“開發(fā)環(huán)境用假數(shù)據(jù)/假服務(wù)生產(chǎn)環(huán)境用真實(shí)服務(wù)”的場(chǎng)景。不過(guò)我建議盡量少用這種分支邏輯因?yàn)樗鼤?huì)讓注冊(cè)信息分散、難審計(jì)。更規(guī)范的做法是把不同環(huán)境的注冊(cè)邏輯封裝成IServiceCollection擴(kuò)展方法按環(huán)境命名比如AddFakeNotificationServices()和AddRealNotificationServices()然后在Program.cs里按環(huán)境調(diào)用。6. 調(diào)試與性能IEnumerable 注入、驗(yàn)證作用域與避免頻繁解析依賴注入用多了你會(huì)發(fā)現(xiàn)大部分問(wèn)題不是“不會(huì)用”而是“出問(wèn)題時(shí)不知道怎么查”。這一章我聊聊調(diào)試和性能優(yōu)化的一些實(shí)操經(jīng)驗(yàn)。6.1 所有注冊(cè)的服務(wù)都能通過(guò)IEnumerableT獲取在 ASP.NET Core 的容器里如果你注冊(cè)了多個(gè)IFoo的實(shí)現(xiàn)那么注入IEnumerableIFoo時(shí)會(huì)拿到所有注冊(cè)的實(shí)例順序按照注冊(cè)順序。這個(gè)特性有兩個(gè)常見的用途實(shí)現(xiàn)某種“策略集合”循環(huán)調(diào)用每個(gè)策略。典型的例子是多個(gè)校驗(yàn)器按順序執(zhí)行直到有一個(gè)不通過(guò)。做插件化架構(gòu)時(shí)動(dòng)態(tài)加載程序集里所有實(shí)現(xiàn)了某個(gè)接口的類然后統(tǒng)一注冊(cè)統(tǒng)一解析。我見過(guò)不少人為了拿到多個(gè)實(shí)現(xiàn)自己維護(hù)一個(gè)列表清單然后在注冊(cè)時(shí)逐個(gè) new。其實(shí)完全可以依賴容器本身用IEnumerableT注入。但注意這個(gè)特性和“按名字獲取具體實(shí)現(xiàn)”不一樣。如果你需要“根據(jù) key 精確獲取某一個(gè)”還是得回到工廠模式或字典映射。6.2 啟動(dòng)時(shí)驗(yàn)證作用域把問(wèn)題暴露在啟動(dòng)階段而不是請(qǐng)求階段ASP.NET Core 提供了ValidateScopes選項(xiàng)用于在啟動(dòng)時(shí)檢測(cè)“從根容器解析 Scoped 服務(wù)”這類錯(cuò)誤。開發(fā)環(huán)境下默認(rèn)是開啟的生產(chǎn)環(huán)境默認(rèn)是關(guān)閉的出于性能考慮。但如果你吃了“Singleton 依賴 Scoped”的虧建議在生產(chǎn)環(huán)境也開啟這個(gè)驗(yàn)證代價(jià)只是啟動(dòng)時(shí)稍微多做一點(diǎn)檢查但能在部署早期就把問(wèn)題暴露出來(lái)。在 .NET 6 的程序里可以這樣配置var builder WebApplication.CreateBuilder(args); builder.Host.UseDefaultServiceProvider(options { options.ValidateScopes true; // 驗(yàn)證作用域 options.ValidateOnBuild true; // 啟動(dòng)時(shí)構(gòu)建驗(yàn)證 });ValidateOnBuild更狠一點(diǎn)會(huì)在容器構(gòu)建完成后立即嘗試解析所有注冊(cè)的服務(wù)檢查構(gòu)造函數(shù)依賴是否都能滿足、有沒(méi)有明顯的循環(huán)依賴。這個(gè)對(duì)大型項(xiàng)目特別友好因?yàn)楹芏鄦?wèn)題不用等到運(yùn)行時(shí)請(qǐng)求才暴露。我記得有一次在重構(gòu)一個(gè)老項(xiàng)目把幾個(gè)服務(wù)從靜態(tài)類改成 DI 注冊(cè)結(jié)果啟動(dòng)到一個(gè)數(shù)據(jù)庫(kù)服務(wù)時(shí)總是報(bào)“Unable to resolve service”錯(cuò)誤。打開ValidateOnBuild后啟動(dòng)日志直接把缺失依賴的服務(wù)名打印得清清楚楚我順著依賴鏈一個(gè)個(gè)補(bǔ)注冊(cè)十分鐘就搞定了。以前要是靠跑起來(lái)之后某個(gè)請(qǐng)求才觸發(fā)那排查時(shí)間得多花好幾倍。6.3 性能陷阱頻繁從 IServiceProvider 解析不是免費(fèi)的IServiceProvider.GetService()的解析成本雖然不算高但也絕不是零成本。在熱路徑比如循環(huán)、高頻接口調(diào)用里反復(fù)解析服務(wù)會(huì)造成可感知的 CPU 開銷。我見過(guò)一個(gè)性能問(wèn)題某個(gè)中間件在每次請(qǐng)求里用了十幾次RequestServices.GetService()雖然每次只有微秒級(jí)消耗但疊加到每秒幾萬(wàn)請(qǐng)求的規(guī)模上浪費(fèi)就很明顯了。最直接的優(yōu)化方式是把服務(wù)依賴挪到構(gòu)造函數(shù)里注入而不是在方法內(nèi)部每次解析。對(duì)于必須動(dòng)態(tài)解析的場(chǎng)景比如策略模式、選路邏輯可以將解析結(jié)果緩存到一個(gè)局部變量中循環(huán)外解析循環(huán)內(nèi)復(fù)用。6.4 陷阱容器釋放順序與 IDisposable服務(wù)如果實(shí)現(xiàn)了IDisposable容器負(fù)責(zé)在生命周期結(jié)束時(shí)釋放它。Singleton 在應(yīng)用停止時(shí)釋放Scoped 在請(qǐng)求結(jié)束時(shí)釋放Transient 在解析者釋放時(shí)釋放如果解析者沒(méi)有釋放容器也會(huì)在 Scope 釋放時(shí)統(tǒng)一釋放。關(guān)于這塊有個(gè)容易被誤解的點(diǎn)如果你手動(dòng)new出來(lái)一個(gè)服務(wù)沒(méi)有經(jīng)過(guò)容器容器是不知道也不負(fù)責(zé)釋放的你需要自己管理它的生命周期。還有一個(gè)小坑如果你用工廠注冊(cè)AddTransientIFoo(sp new Foo())返回一個(gè)實(shí)現(xiàn)了IDisposable的對(duì)象容器會(huì)跟蹤并釋放它前提是它是在容器解析時(shí)創(chuàng)建的。如果你的工廠返回的是一個(gè)已經(jīng)存在的單例比如靜態(tài)實(shí)例容器可能會(huì)重復(fù)釋放同一個(gè)對(duì)象這時(shí)候要格外小心。經(jīng)驗(yàn)是讓容器管理生命周期不要在工廠里返回自己管理生命周期的“外來(lái)對(duì)象”除非你確認(rèn)不會(huì)出現(xiàn)重復(fù)釋放問(wèn)題。7. 架構(gòu)層面的實(shí)踐接口、模塊化注冊(cè)與可測(cè)試性依賴注入的最終勝利不在于“會(huì)用”而在于“用得順手”。我自己在架構(gòu)層面有幾條心得分享給大家。7.1 每個(gè)項(xiàng)目都按模塊拆分注冊(cè)擴(kuò)展方法我參與過(guò)的項(xiàng)目中最容易失控的是那個(gè)巨無(wú)霸Program.cs或Startup.cs。幾十個(gè)AddSomething()擠在一起誰(shuí)也不敢動(dòng)改一行都心驚膽戰(zhàn)。后來(lái)我養(yǎng)成了一個(gè)習(xí)慣每個(gè)業(yè)務(wù)模塊自己寫一個(gè)服務(wù)注冊(cè)擴(kuò)展方法內(nèi)部只負(fù)責(zé)本模塊依賴的服務(wù)然后在Program.cs里調(diào)用它。舉個(gè)例子一個(gè)“訂單模塊”可以有一個(gè)public static class OrderServiceCollectionExtensions { public static IServiceCollection AddOrderModule(this IServiceCollection services) { services.AddScopedIOrderRepository, SqlOrderRepository(); services.AddScopedIOrderService, OrderService(); services.AddScopedIOrderDomainEventHandler, OrderDomainEventHandler(); return services; } }Program.cs里三五行就搞定builder.Services.AddInfrastructureModule(); builder.Services.AddOrderModule(); builder.Services.AddPaymentModule();這樣每個(gè)模塊的依賴關(guān)系集中在模塊自己的擴(kuò)展方法里找問(wèn)題的時(shí)候直接進(jìn)模塊文件不用在啟動(dòng)文件里撈針。配合上模塊化項(xiàng)目的層次結(jié)構(gòu)應(yīng)用層、領(lǐng)域?qū)印⒒A(chǔ)設(shè)施層、表現(xiàn)層每一層的 DI 注冊(cè)職責(zé)也能被清晰劃分。7.2 用容器做依賴注入但也別把一切都扔進(jìn)容器有一類東西我不建議放容器里。比如配置對(duì)象直接用IOptionsT、靜態(tài)工具類如MathHelper、簡(jiǎn)單的數(shù)據(jù)傳輸對(duì)象DTO。容器存在的意義是管理復(fù)雜依賴關(guān)系和生命周期如果什么東西都硬塞進(jìn)容器解析鏈會(huì)越來(lái)越長(zhǎng)性能下降排查也麻煩。還有一類需要小心的是“長(zhǎng)期存在的服務(wù)”和“短期請(qǐng)求”混合的情況。比如 Singleton 的緩存服務(wù)里不小心引用了 Scoped 的DbContext這就是架構(gòu)層面的錯(cuò)誤。我給出的建議很簡(jiǎn)單畫一條依賴規(guī)則——Singleton 只能依賴 SingletonScoped 可以依賴 Scoped 和 SingletonTransient 可以依賴任意生命周期。寫進(jìn)團(tuán)隊(duì)規(guī)范當(dāng)作評(píng)審時(shí)的關(guān)注點(diǎn)。7.3 依賴注入如何讓測(cè)試變得更簡(jiǎn)單依賴注入最大的工程紅利是“可測(cè)試性”。因?yàn)橐粋€(gè)類的依賴都是通過(guò)接口注進(jìn)來(lái)的測(cè)試時(shí)你可以隨手替換成假的實(shí)現(xiàn)不需要啟動(dòng)整個(gè)應(yīng)用不需要碰數(shù)據(jù)庫(kù)不需要真實(shí)發(fā)郵件。我寫單元測(cè)試時(shí)的做法是[Fact] public async Task GetWeatherAsync_WhenCityIsEmpty_ThrowsArgumentException() { var weatherService new WeatherService( Mock.OfIWeatherRepository(), Mock.OfICacheService()); await Assert.ThrowsAsyncArgumentException( () weatherService.GetWeatherAsync()); }這里每個(gè)依賴都能用 mock 對(duì)象替代測(cè)試用例短小明確。如果沒(méi)有依賴注入你可能要花大力氣構(gòu)造WeatherService的內(nèi)部依賴甚至要起一個(gè)完整的服務(wù)宿主測(cè)試效率和可維護(hù)性都差很多。7.4 依賴注入與模塊化邊界別讓容器變成“上帝對(duì)象”有一種反模式是為了讓某個(gè)服務(wù)在任何地方都能拿到把它注冊(cè)成 Singleton然后在幾乎每個(gè)類里注入它。這會(huì)造成隱式的全局依賴代碼之間通過(guò)這個(gè)“上帝對(duì)象”互相通信模塊邊界名存實(shí)亡。我在一些老項(xiàng)目里見過(guò)這種現(xiàn)象整改起來(lái)特別痛苦。正確的做法是依賴關(guān)系要顯式地通過(guò)構(gòu)造函數(shù)表達(dá)出來(lái)。如果一個(gè)類需要“當(dāng)前用戶信息”不要讓它自己去全局容器里拿而是讓調(diào)用方把用戶信息顯式傳進(jìn)來(lái)。容器只用來(lái)組裝那些“真正需要容器管理的服務(wù)”不要用它作為傳遞參數(shù)的通道。這一點(diǎn)做得好模塊邊界才能保持清晰。8. 那些坑循環(huán)依賴、作用域失控與我沒(méi)能早發(fā)現(xiàn)的錯(cuò)誤最后一個(gè)大章節(jié)聊幾個(gè)實(shí)際項(xiàng)目中經(jīng)常踩的坑。這些坑每個(gè)我都見過(guò)或者親身體驗(yàn)過(guò)希望你們能提前避雷。8.1 循環(huán)依賴兩個(gè)服務(wù)互相引用彼此依賴注入最經(jīng)典的報(bào)錯(cuò)之一A依賴BB又依賴A。容器在嘗試解析時(shí)會(huì)發(fā)現(xiàn)依賴鏈成了一個(gè)環(huán)然后拋出異常。解決辦法一般有三種重構(gòu)拆分把 A 和 B 之間互相依賴的那部分邏輯抽出來(lái)放到第三個(gè)類 C 里A 和 B 都依賴 C循環(huán)自然解除。這是最徹底的方案也是我最推薦的方式。改變生命周期如果 A 和 B 都是 Transient改成其中一個(gè)為 Singleton 或 Scoped有時(shí)能繞過(guò)構(gòu)建循環(huán)的問(wèn)題。但這治標(biāo)不治本潛在風(fēng)險(xiǎn)仍然在。延遲解析某個(gè)服務(wù)在真正用到時(shí)才去容器解析通過(guò)注入IServiceProvider而不是在構(gòu)造函數(shù)里直接依賴?？梢越鉀Q問(wèn)題但代價(jià)是“依賴關(guān)系變隱式了”而且會(huì)破壞構(gòu)造函數(shù)注入的清晰性。我的經(jīng)驗(yàn)是遇到循環(huán)依賴先停下來(lái)想想設(shè)計(jì)問(wèn)題而不是急著找 hack。循環(huán)依賴通常意味著職責(zé)邊界劃分不當(dāng)。重構(gòu)雖然工作量大一點(diǎn)但以后維護(hù)的舒適度完全值得。8.2 作用域失控一個(gè) Scoped 服務(wù)被 Singleton 持有了這個(gè)坑我在生命周期章節(jié)提過(guò)但值得再具體演示一下。假設(shè)你有一個(gè)ICacheService注冊(cè)成了 Singleton而它內(nèi)部注入了IBillingRepositoryScoped。容器啟動(dòng)時(shí)不會(huì)立刻檢測(cè)到錯(cuò)誤除非開啟了ValidateOnBuild但等到某個(gè)請(qǐng)求使用了這個(gè)緩存服務(wù)運(yùn)行時(shí)就會(huì)拋出異常。這類問(wèn)題最陰險(xiǎn)的地方是它不一定在啟動(dòng)階段出現(xiàn)而是取決于哪個(gè)請(qǐng)求先觸發(fā)。A 客戶端的請(qǐng)求觸發(fā)了一切正常B 客戶端的請(qǐng)求觸發(fā)了直接 500。我見過(guò)一個(gè)項(xiàng)目因?yàn)檫@個(gè)原因偶發(fā)崩潰排查了好久才定位到這層關(guān)系。最好的防線就是我在前面說(shuō)的同一個(gè)服務(wù)生命周期統(tǒng)一Singleton 依賴鏈上全部是 Singleton在開發(fā)環(huán)境開啟服務(wù)作用域驗(yàn)證。這三條做到了這類坑基本能全部躲掉。8.3 過(guò)度注入構(gòu)造函數(shù)動(dòng)不動(dòng)就七八個(gè)參數(shù)如果一個(gè)服務(wù)類構(gòu)造函數(shù)里要注入七八個(gè)東西這個(gè)類八成違背了“單一職責(zé)原則”。七八個(gè)依賴意味著它同時(shí)在做好幾件事。我見過(guò)最夸張的某個(gè)服務(wù)構(gòu)造函數(shù)里塞了 12 個(gè)依賴每次修改都要傳新參數(shù)測(cè)試時(shí) mock 也要寫 12 行。重構(gòu)思路是拆類把數(shù)據(jù)庫(kù)訪問(wèn)拆出去、把通知拆出去、把緩存拆出去然后用門面模式或組合模式把幾個(gè)小服務(wù)組合起來(lái)。依賴注入容器擅長(zhǎng)組裝所以“很多小對(duì)象組合成一個(gè)大對(duì)象”是合理的但“一個(gè)大對(duì)象硬吞進(jìn)無(wú)數(shù)依賴”是不合理的。8.4 忘記釋放 scope 資源在手動(dòng)創(chuàng)建 Scope 的場(chǎng)景里后臺(tái)任務(wù)、控制臺(tái)應(yīng)用如果忘記using釋放 ScopeScoped 服務(wù)里創(chuàng)建的DbContext、HTTP 客戶端連接等資源就會(huì)一直占著內(nèi)存時(shí)間長(zhǎng)了可能引發(fā)連接池耗盡、內(nèi)存泄漏。我給自己定的習(xí)慣是所有手動(dòng)創(chuàng)建的 Scope 一律用using或await using包起來(lái)確保離開代碼塊就釋放。哪怕只是解析一個(gè)不痛不癢的小服務(wù)也養(yǎng)成這個(gè)習(xí)慣免得哪天換成DbContext時(shí)踩雷。8.5 啟動(dòng)時(shí)解析 Scoped 服務(wù)的“想當(dāng)然”錯(cuò)誤前面說(shuō)過(guò)在Program.cs或Startup.cs里直接解析 Scoped 服務(wù)是個(gè)常見的坑。比如有人想在啟動(dòng)時(shí)初始化 admin 用戶var adminService app.Services.GetRequiredServiceIAdminService(); adminService.Initialize();如果IAdminService注冊(cè)的是 Scoped這段代碼會(huì)直接報(bào)錯(cuò)未開啟ValidateScopes時(shí)也可能不報(bào)錯(cuò)但行為不保證。正確寫法using (var scope app.Services.CreateScope()) { var adminService scope.ServiceProvider.GetRequiredServiceIAdminService(); adminService.Initialize(); }這個(gè)“手動(dòng)開 Scope 解析服務(wù)”的模式在 .NET 6 的WebApplication環(huán)境里尤其常見因?yàn)镻rogram.cs里寫啟動(dòng)邏輯的人很多。記住一條根容器的ApplicationServices是用來(lái)解析 Singleton 和通過(guò)工廠解析服務(wù)的不是給你解析 Scoped 服務(wù)的。9. 我的推薦實(shí)踐從開發(fā)到生產(chǎn)環(huán)境一路穩(wěn)最后我給出一份我在實(shí)際項(xiàng)目里會(huì)用的“依賴注入實(shí)踐清單”。這些條不是什么金科玉律但經(jīng)過(guò)多個(gè)項(xiàng)目的錘煉確實(shí)能幫我少踩很多坑。注冊(cè)入口盡量集中在模塊擴(kuò)展方法里不要在Program.cs里散落大量注冊(cè)代碼。每個(gè)模塊對(duì)自己負(fù)責(zé)注冊(cè)代碼的查找成本極大降低。生命周期統(tǒng)一且顯式同一個(gè)服務(wù)類型只注冊(cè)一種生命周期。注冊(cè) Unity 時(shí)團(tuán)隊(duì)規(guī)范里寫明“所有服務(wù)必須顯式指定生命周期”不允許使用默認(rèn)的自動(dòng)注冊(cè)工具把一切都變成 Transient 或 Singleton。在開發(fā)環(huán)境和生產(chǎn)環(huán)境都開啟ValidateScopes。雖然生產(chǎn)環(huán)境有一些性能開銷但換來(lái)的是早期發(fā)現(xiàn)生命周期錯(cuò)誤。如果對(duì)性能極度敏感可以在生產(chǎn)環(huán)境關(guān)閉但要保證測(cè)試和預(yù)發(fā)布環(huán)境開啟。堅(jiān)持構(gòu)造函數(shù)注入避免屬性注入和服務(wù)定位器模式。構(gòu)造函數(shù)注入最顯式依賴關(guān)系一目了然。雖然屬性注入寫起來(lái)更少但“依賴關(guān)系隱式化”后代碼的可讀性和可測(cè)性會(huì)變差。使用IOptionsT來(lái)管理配置不要直接把配置對(duì)象注冊(cè)成 Singleton。這樣配置的刷新、熱更新才有標(biāo)準(zhǔn)支持測(cè)試時(shí)替換配置也更靈活。對(duì)資源型服務(wù)比如 DbContext、數(shù)據(jù)庫(kù)連接優(yōu)先使用 Scoped并且確保在請(qǐng)求管道或手動(dòng) Scope 里使用。如果需要在后臺(tái)任務(wù)里使用就手動(dòng)創(chuàng)建并釋放 Scope。依賴方向只允許單向流動(dòng)接口定義在一個(gè)模塊實(shí)現(xiàn)放在基礎(chǔ)設(shè)施層應(yīng)用層只依賴接口。這樣 Web API、后臺(tái)任務(wù)、測(cè)試都能共用同一個(gè)接口層模塊之間的耦合被降到最低。定期做依賴關(guān)系審計(jì)可以寫一個(gè)簡(jiǎn)單的構(gòu)建腳本在 CI 階段把服務(wù)注冊(cè)列表輸出到日志里看看有沒(méi)有某個(gè)模塊的注冊(cè)依賴異常。這個(gè)對(duì)團(tuán)隊(duì)協(xié)作特別有幫助。我可以坦誠(chéng)地說(shuō)依賴注入這套機(jī)制我自己從“會(huì)用”到“覺得香”經(jīng)歷了挺長(zhǎng)時(shí)間。很多經(jīng)驗(yàn)也是靠踩坑換來(lái)的——特別是那幾個(gè)生命周期相關(guān)的坑我至今記憶猶新。希望這篇長(zhǎng)文能幫你把 ASP.NET Core 依賴注入從“知道概念”推向“理解本質(zhì)”以后在項(xiàng)目里用它建模、設(shè)計(jì)服務(wù)邊界、排查疑難問(wèn)題的時(shí)候能更有底氣。 ASP.NET Core依賴注入實(shí)戰(zhàn)：生命周期、作用域與高級(jí)玩法
1. 為什么說(shuō)依賴注入是 ASP.NET Core 的“地基”我第一次接觸 ASP.NET Core 的時(shí)候最直觀的感受就是這和舊的 .NET Framework 時(shí)代寫代碼的方式完全不一樣了。以前在 ASP.NET MVC 5 里想要在控制器里用一個(gè)服務(wù)通常就是new一個(gè)出來(lái)或者借助某個(gè)靜態(tài)類、某個(gè)單例工廠去拿。那時(shí)候項(xiàng)目里的服務(wù)之間互相 new、互相依賴代碼耦合得像一團(tuán)亂麻測(cè)試更是難以下手。而 ASP.NET Core 從出生那天起就把依賴注入DI做進(jìn)了框架的骨髓里。你看到的Startup類里的ConfigureServices方法、控制器構(gòu)造函數(shù)里直接聲明接口參數(shù)、中間件里通過(guò)RequestServices獲取服務(wù)這些都是依賴注入在背后起作用?？梢哉f(shuō)不搞懂依賴注入你根本沒(méi)法理解 ASP.NET Core 的應(yīng)用是怎么被組裝起來(lái)的。那依賴注入到底解決了什么問(wèn)題我用一句話概括它把“創(chuàng)建依賴”這件事從你手里拿走交給你注冊(cè)的容器統(tǒng)一管理。比如你的業(yè)務(wù)服務(wù)OrderService依賴一個(gè)IOrderRepository傳統(tǒng)寫法里你必須在OrderService內(nèi)部親手new一個(gè)具體的SqlOrderRepository。一旦換了數(shù)據(jù)庫(kù)、換了實(shí)現(xiàn)方式你得跑到每一處new的地方去改。而依賴注入的做法是OrderService只需要在構(gòu)造函數(shù)里聲明“我需要一個(gè)IOrderRepository”至于這個(gè)接口到底由哪個(gè)類來(lái)實(shí)現(xiàn)、生命周期是多久全部交給容器在注冊(cè)時(shí)決定。這不只是“解耦”兩個(gè)字那么簡(jiǎn)單。它直接改變了你組織代碼的方式。以前你寫代碼的粒度通常是“類”而現(xiàn)在你會(huì)下意識(shí)地按照“接口 實(shí)現(xiàn) 注冊(cè)”的方式來(lái)組織。你會(huì)更自然地拆出小服務(wù)、小組件每個(gè)組件只干一件事組件之間通過(guò)接口通信。這種代碼風(fēng)格一旦形成習(xí)慣項(xiàng)目的可維護(hù)性會(huì)肉眼可見地提升。我在帶團(tuán)隊(duì)的時(shí)候經(jīng)常說(shuō)依賴注入不只是一個(gè)框架功能它是一套編碼思維。你理解了它再看 ASP.NET Core 的管道、中間件、配置系統(tǒng)、日志系統(tǒng)都會(huì)覺得處處相通因?yàn)檫@些底層機(jī)制全都建立在 DI 容器之上。反過(guò)來(lái)如果你只是照著模板抄代碼碰到“在構(gòu)造函數(shù)里注入某個(gè)服務(wù)”的寫法也只會(huì)在用到的時(shí)候照貓畫虎一旦遇到循環(huán)依賴、生命周期沖突這種疑難雜癥就會(huì)一臉懵。所以這篇文章我想把自己在實(shí)際項(xiàng)目里折騰依賴注入的經(jīng)驗(yàn)整理出來(lái)。從核心概念、生命周期到實(shí)戰(zhàn)中繞不開的高級(jí)玩法比如工廠模式、裝飾器模式、Scope 驗(yàn)證再到踩過(guò)的坑和調(diào)試技巧爭(zhēng)取講得既有原理又有干貨。不管你是剛接觸 ASP.NET Core 的新手還是寫著寫著總覺得哪里不對(duì)勁的老手應(yīng)該都能從里面找到一些有價(jià)值的東西。2. 從IServiceProvider說(shuō)起容器到底替我們做了什么很多人上來(lái)就背“構(gòu)造函數(shù)注入”“AddScoped”“AddTransient”但這些概念背熟以后腦子里依然是一團(tuán)漿糊。我的建議是先弄懂最底層的那個(gè)對(duì)象——IServiceProvider。在 ASP.NET Core 里整個(gè)應(yīng)用其實(shí)就是一個(gè)“服務(wù)集合”的組裝結(jié)果。你寫builder.Services.AddXxx()的時(shí)候本質(zhì)上是在往一個(gè)ServiceCollection里添加服務(wù)描述。這個(gè)ServiceCollection就像一張菜單列著“什么接口對(duì)應(yīng)什么實(shí)現(xiàn)以什么生命周期來(lái)創(chuàng)建”。等到應(yīng)用啟動(dòng)框架根據(jù)這張菜單構(gòu)建出一個(gè)IServiceProvider實(shí)例也就是真正的“服務(wù)容器”。IServiceProvider的核心只有一個(gè)方法object GetService(Type serviceType)。你告訴它你想要什么類型它就根據(jù)之前注冊(cè)的規(guī)則幫你把這個(gè)類型以及它依賴的東西完整地實(shí)例化出來(lái)。聽起來(lái)簡(jiǎn)單但這背后牽扯出幾個(gè)關(guān)鍵問(wèn)題構(gòu)造函數(shù)里要的參數(shù)怎么來(lái)同一個(gè)服務(wù)被請(qǐng)求多次時(shí)是返回同一個(gè)實(shí)例還是每次都新建如果服務(wù)之間有循環(huán)依賴怎么處理我用一個(gè)生活里的類比來(lái)解釋服務(wù)容器就像一個(gè)全能中介。你要租房子解析IOrderRepository中介會(huì)根據(jù)你的需求去匹配房東具體實(shí)現(xiàn)類SqlOrderRepository。如果房子需要配家具構(gòu)造函數(shù)依賴DbContext中介還會(huì)順手聯(lián)系家具商解析DbContext把家具也安排到位。你只需要告訴中介“我要什么”剩下的一堆復(fù)雜流程都不用管。實(shí)際寫代碼的時(shí)候最常用的入口有四個(gè)IServiceProvider直接獲取服務(wù)實(shí)例IServiceScopeFactory創(chuàng)建子作用域IServiceScope作用域本身ActivatorUtilities在容器之外輔助創(chuàng)建對(duì)象同時(shí)盡量解析其依賴其中IServiceScopeFactory是很多人一開始容易忽略的。在后臺(tái)任務(wù)、控制臺(tái)應(yīng)用、或者某些需要“手動(dòng)解析服務(wù)”的場(chǎng)景里你往往會(huì)用serviceProvider.CreateScope()創(chuàng)建一個(gè)作用域來(lái)拿服務(wù)。如果不這么做直接拿IServiceProvider.GetService(typeof(MyService))去解析一個(gè) Scoped 服務(wù)大概率會(huì)得到一個(gè)異?；蛘吣玫揭粋€(gè)不按預(yù)期生命周期工作的實(shí)例。關(guān)于這點(diǎn)我踩過(guò)比較經(jīng)典的坑是在 ASP.NET Core 的 Startup 階段嘗試解析 Scoped 服務(wù)。比如有人想在Configure方法里通過(guò)app.ApplicationServices.GetServiceMyDbContext()直接拿數(shù)據(jù)庫(kù)上下文去初始化數(shù)據(jù)。運(yùn)行起來(lái)會(huì)發(fā)現(xiàn)這種方式在某些版本里能拿到對(duì)象但 DbContext 的跟蹤行為、連接管理并不符合預(yù)期甚至可能因?yàn)樽饔糜蛉笔?dǎo)致連接沒(méi)有及時(shí)釋放。正確做法是手動(dòng)創(chuàng)建一個(gè) Scope在這個(gè) Scope 里拿 DbContext 用用完釋放。這個(gè)細(xì)節(jié)我在后面的生命周期章節(jié)里還會(huì)重點(diǎn)展開。理解了IServiceProvider你就抓住了 DI 容器的“心臟”。后面聊生命周期、聊擴(kuò)展點(diǎn)都是圍繞這個(gè)核心展開的。3. 生命周期三兄弟Transient、Scoped、Singleton 到底怎么選ASP.NET Core 的 DI 容器支持三種生命周期模式這恐怕是日常開發(fā)里討論最多、也最容易出問(wèn)題的地方。先說(shuō)定義再說(shuō)我的理解最后講實(shí)操選擇。生命周期創(chuàng)建時(shí)機(jī)特點(diǎn)典型場(chǎng)景Transient瞬態(tài)每次從容器解析時(shí)都新建實(shí)例最輕、無(wú)狀態(tài)輕量工具類、無(wú)狀態(tài)服務(wù)Scoped作用域每個(gè)作用域內(nèi)只創(chuàng)建一個(gè)實(shí)例一個(gè)請(qǐng)求一個(gè)實(shí)例DbContext、業(yè)務(wù)服務(wù)Singleton單例整個(gè)應(yīng)用生命周期內(nèi)只有一個(gè)實(shí)例全局共享緩存、配置、日志提供者定義大家都懂但實(shí)際選擇時(shí)經(jīng)常有爭(zhēng)議。我覺得關(guān)鍵要把握兩條原則有沒(méi)有狀態(tài)狀態(tài)的生命周期應(yīng)該有多長(zhǎng)Singleton適合“無(wú)狀態(tài)或有意共享狀態(tài)”的服務(wù)。比如一個(gè)MemoryCache包裝類全局只有一個(gè)實(shí)例里面的數(shù)據(jù)在所有請(qǐng)求之間共享這很合理。但如果你把一個(gè)有狀態(tài)的類比如包含可變字段的服務(wù)注冊(cè)成 Singleton就要警惕多線程并發(fā)問(wèn)題。多個(gè)請(qǐng)求同時(shí)讀寫同一個(gè)實(shí)例的字段輕則數(shù)據(jù)錯(cuò)亂重則出現(xiàn)難以復(fù)現(xiàn)的 bug。Scoped適合“一個(gè)請(qǐng)求內(nèi)保持一致”的服務(wù)。最典型的就是DbContext。一個(gè) HTTP 請(qǐng)求里你可能會(huì)在多個(gè)地方使用數(shù)據(jù)庫(kù)上下文如果每個(gè)地方都拿到不同的 DbContext 實(shí)例那么它們各自跟蹤不同的實(shí)體狀態(tài)事務(wù)和性能都是災(zāi)難。Scoped 保證同一個(gè)請(qǐng)求范圍內(nèi)拿到的都是同一個(gè)實(shí)例這個(gè)問(wèn)題就自然解決了。Transient適合“每次使用都獨(dú)立”的服務(wù)。比如一個(gè)EmailValidator它內(nèi)部只保存驗(yàn)證規(guī)則不保存用戶狀態(tài)每次新建一個(gè)實(shí)例成本很低也無(wú)所謂共享。再比如有些服務(wù)內(nèi)部依賴了另一個(gè) Transient 服務(wù)每次解析都需要一個(gè)干凈的組合那么 Transient 就是合適的選擇。但實(shí)際項(xiàng)目里經(jīng)常出現(xiàn)“看似無(wú)狀態(tài)其實(shí)有隱含狀態(tài)”的服務(wù)這是最坑的。我舉一個(gè)例子你寫了一個(gè)AuditLogger構(gòu)造函數(shù)里注入了一個(gè)IHttpContextAccessor用來(lái)記錄當(dāng)前請(qǐng)求的用戶信息。表面上看它沒(méi)有字段、沒(méi)有狀態(tài)非常適合注冊(cè)成 Singleton。但I(xiàn)HttpContextAccessor本身是 Scoped 的它的內(nèi)部邏輯依賴請(qǐng)求上下文如果你把AuditLogger注冊(cè)成 Singleton而它又注入了 Scoped 的IHttpContextAccessor這時(shí)候容器就會(huì)拋異常。為什么因?yàn)?Singleton 的實(shí)例在應(yīng)用啟動(dòng)時(shí)就創(chuàng)建了它不像請(qǐng)求那樣有明確的生命周期邊界。如果允許一個(gè) Singleton 持有 Scoped 服務(wù)的引用那么這個(gè) Scoped 服務(wù)到底是哪個(gè)請(qǐng)求的容器沒(méi)法回答這個(gè)問(wèn)題所以干脆在注冊(cè)時(shí)就不允許這種依賴關(guān)系。這就是著名的“生命周期捕獲”問(wèn)題是 ASP.NET Core DI 新手最容易踩的大坑之一。我也碰到過(guò)這種情況一個(gè)實(shí)現(xiàn)類被同時(shí)注冊(cè)成了 Scoped 和 Singleton 兩種方式代碼里有些地方用的是 Scoped 的解析有些地方用的是 Singleton 的解析。結(jié)果是同一個(gè)邏輯在某些請(qǐng)求里共享狀態(tài)在某些請(qǐng)求里又各自獨(dú)立排查問(wèn)題的時(shí)候讓人非常抓狂。我后來(lái)給自己定了一條規(guī)矩同一個(gè)服務(wù)類型在整個(gè)容器中只注冊(cè)一種生命周期除非有極其特殊的需求否則絕不在多個(gè)地方用不同生命周期重復(fù)注冊(cè)。4. Scope 與請(qǐng)求管道為什么你的服務(wù)在一個(gè)“虛擬邊界”里工作前面反復(fù)提到“作用域Scope”這個(gè)詞對(duì)新手來(lái)說(shuō)有點(diǎn)抽象。我盡量用最直白的方式拆開講。其實(shí) Scope 就是容器創(chuàng)建的一組服務(wù)實(shí)例的“集合邊界”。在 ASP.NET Core 的請(qǐng)求管道里框架會(huì)在每個(gè) HTTP 請(qǐng)求開始時(shí)自動(dòng)創(chuàng)建一個(gè) Scope并在請(qǐng)求結(jié)束時(shí)把它釋放。這個(gè) Scope 里解析的所有 Scoped 服務(wù)生命周期都跟這一個(gè)請(qǐng)求綁定。請(qǐng)求開始服務(wù)創(chuàng)建請(qǐng)求結(jié)束服務(wù)釋放。整個(gè)過(guò)程你基本不需要手動(dòng)干預(yù)框架已經(jīng)幫你處理好了。但這個(gè)“自動(dòng)”背后有一個(gè)重要前提你的代碼必須沿著請(qǐng)求管道走。如果你的代碼是在請(qǐng)求之外的上下文里執(zhí)行比如后臺(tái)托管服務(wù)、定時(shí)任務(wù)、消息隊(duì)列消費(fèi)者那就沒(méi)有現(xiàn)成的 Scope 可用。這時(shí)候如果你直接解析 Scoped 服務(wù)就會(huì)遇到我前面說(shuō)的麻煩。我舉個(gè)例子。假定你寫了一個(gè)IHostedService在應(yīng)用啟動(dòng)后每 30 秒執(zhí)行一次數(shù)據(jù)清理任務(wù)。任務(wù)里要用到MyDbContextScoped如果你直接注入MyDbContext到后臺(tái)服務(wù)構(gòu)造函數(shù)里應(yīng)用啟動(dòng)時(shí)容器就會(huì)報(bào)錯(cuò)因?yàn)镮HostedService本身是 Singleton 的它不能依賴 Scoped 服務(wù)。解決方式是在后臺(tái)任務(wù)的每次執(zhí)行中手動(dòng)創(chuàng)建 Scopepublic class CleanupHostedService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; public CleanupHostedService(IServiceScopeFactory scopeFactory) { _scopeFactory scopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using (var scope _scopeFactory.CreateScope()) { var dbContext scope.ServiceProvider.GetRequiredServiceMyDbContext(); // 執(zhí)行清理邏輯 } await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken); } } }這里的關(guān)鍵是IServiceScopeFactory本身是 Singleton 安全的你可以放心地把它注入到任何地方。每次要干活的時(shí)候用CreateScope()開一個(gè)新的“小容器”在這個(gè)小容器里解析 Scoped 服務(wù)用完立刻釋放。這樣既遵守了生命周期規(guī)則又不會(huì)出現(xiàn)“Singleton 依賴 Scoped”的沖突。我在實(shí)際項(xiàng)目里把這個(gè)模式用得非常頻繁尤其是寫后臺(tái)任務(wù)、定時(shí)任務(wù)、消息隊(duì)列消費(fèi)者的時(shí)候?？梢赃@么理解凡是離開了 HTTP 請(qǐng)求管道、又需要解析 Scoped 服務(wù)的場(chǎng)景都要養(yǎng)成“手動(dòng)開 Scope”的習(xí)慣。這不是可選項(xiàng)是必須項(xiàng)否則你拿到的要么是異常要么是行為詭異的服務(wù)實(shí)例。還有一個(gè)容易被忽略的場(chǎng)景你在中間件里拿服務(wù)。中間件本身是在請(qǐng)求管道里的所以它默認(rèn)就有 Scope 的上下文。但如果你用RequestServices.GetService()和直接用構(gòu)造函數(shù)注入結(jié)果是不太一樣的。構(gòu)造函數(shù)注入的中間件實(shí)例是 Singleton 創(chuàng)建的它拿不到當(dāng)前請(qǐng)求的 Scope 服務(wù)而通過(guò)RequestServices拿服務(wù)是在當(dāng)前請(qǐng)求的 Scope 里拿的這才是正確姿勢(shì)。我的經(jīng)驗(yàn)是中間件里如果需要依賴 Scoped 服務(wù)優(yōu)先用RequestServices不要指望構(gòu)造函數(shù)注入。構(gòu)造函數(shù)注入適合 Scoped 服務(wù)那種“每個(gè)請(qǐng)求都不同”的場(chǎng)合但中間件只有一個(gè)實(shí)例所以它沒(méi)法持有請(qǐng)求級(jí)別的服務(wù)引用。5. 實(shí)戰(zhàn)技巧工廠模式、裝飾器模式與條件注冊(cè)聊完生命周期我想分享幾個(gè)實(shí)際項(xiàng)目中經(jīng)常用到的高級(jí)玩法。這些玩法不是 AspNet Core DI 的“必學(xué)操作”但如果你經(jīng)歷過(guò)某個(gè)痛點(diǎn)就會(huì)知道它們有多香。5.1 工廠模式同一個(gè)接口多個(gè)實(shí)現(xiàn)怎么處理一個(gè)接口多個(gè)實(shí)現(xiàn)類是 DI 里最直接的挑戰(zhàn)。最常見的是接口IPaymentGateway有支付寶實(shí)現(xiàn)、微信支付實(shí)現(xiàn)、銀聯(lián)實(shí)現(xiàn)你想在運(yùn)行時(shí)根據(jù)上下文選擇具體用哪個(gè)。最笨的辦法是把所有實(shí)現(xiàn)都注冊(cè)上去然后靠IEnumerableIPaymentGateway注入進(jìn)來(lái)自己循環(huán)判斷。但這樣代碼會(huì)越寫越亂。更優(yōu)雅的方案是注冊(cè)一個(gè)工廠委托services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var providerName config[Payment:Provider]; switch (providerName) { case Alipay: return new AlipayGateway(...); case WeChat: return new WeChatGateway(...); default: throw new InvalidOperationException($Unknown provider: {providerName}); } });工廠委托的優(yōu)勢(shì)是你可以在創(chuàng)建服務(wù)時(shí)做復(fù)雜的初始化、根據(jù)配置選擇實(shí)現(xiàn)類、或者做延遲初始化。所以當(dāng)你發(fā)現(xiàn)某個(gè)服務(wù)的構(gòu)造過(guò)程不只是一句new Xxx(params...)的時(shí)候就該考慮用工廠注冊(cè)來(lái)代替默認(rèn)的反射構(gòu)造。5.2 裝飾器模式在不改原代碼的情況下增加橫切邏輯裝飾器模式是 DI 里用來(lái)做“橫切關(guān)注點(diǎn)”的利器。什么叫橫切關(guān)注點(diǎn)比如日志、緩存、性能監(jiān)控、故障恢復(fù)這些邏輯縱向貫穿業(yè)務(wù)代碼把它寫在業(yè)務(wù)服務(wù)內(nèi)部會(huì)讓代碼很臟。舉個(gè)例子。你有一個(gè)IWeatherService里面提供了GetWeatherAsync。你不想改動(dòng)WeatherService本身但想在每次調(diào)用時(shí)記錄耗時(shí)、加緩存、做重試。這時(shí)候你寫一個(gè)LoggingWeatherService它實(shí)現(xiàn)同一個(gè)接口內(nèi)部包裝一個(gè)真實(shí)的IWeatherServicepublic class LoggingWeatherService : IWeatherService { private readonly IWeatherService _inner; private readonly ILoggerLoggingWeatherService _logger; public LoggingWeatherService(IWeatherService inner, ILoggerLoggingWeatherService logger) { _inner inner; _logger logger; } public async TaskWeatherResult GetWeatherAsync(string city) { var sw Stopwatch.StartNew(); try { return await _inner.GetWeatherAsync(city); } finally { _logger.LogInformation(GetWeatherAsync took {Elapsed}ms, sw.ElapsedMilliseconds); } } }注冊(cè)的時(shí)候稍微繞一下services.AddTransientWeatherService(); // 真實(shí)實(shí)現(xiàn) services.AddTransientIWeatherService(sp new LoggingWeatherService(sp.GetRequiredServiceWeatherService(), sp.GetRequiredServiceILoggerLoggingWeatherService()));雖然代碼看起來(lái)多了一點(diǎn)點(diǎn)但好處是業(yè)務(wù)邏輯類根本不知道日志的存在日志邏輯獨(dú)立成一個(gè)類可復(fù)用、可測(cè)試。如果你用 Scrutor 這類庫(kù)還能自動(dòng)掃描程序集批量給所有實(shí)現(xiàn)了某個(gè)接口的類套上裝飾器省去大量手工注冊(cè)代碼。我在項(xiàng)目里用裝飾器做過(guò)緩存、重試、審計(jì)、分布式鎖等橫切能力效果非常棒。它和 AOP面向切面編程的思想一致但在 .NET 世界里不需要引入復(fù)雜的 AOP 框架用 DI 原生的方式就能實(shí)現(xiàn)。5.3 條件注冊(cè)根據(jù)運(yùn)行時(shí)配置決定要不要注冊(cè)某個(gè)服務(wù)依賴注入的條件注冊(cè)不一定要用第三方庫(kù)簡(jiǎn)單的判斷完全可以在ConfigureServices里完成if (environment.IsDevelopment()) { services.AddScopedINotificationSender, FakeNotificationSender(); } else { services.AddScopedINotificationSender, EmailNotificationSender(); }這種寫法最常見于“開發(fā)環(huán)境用假數(shù)據(jù)/假服務(wù)生產(chǎn)環(huán)境用真實(shí)服務(wù)”的場(chǎng)景。不過(guò)我建議盡量少用這種分支邏輯因?yàn)樗鼤?huì)讓注冊(cè)信息分散、難審計(jì)。更規(guī)范的做法是把不同環(huán)境的注冊(cè)邏輯封裝成IServiceCollection擴(kuò)展方法按環(huán)境命名比如AddFakeNotificationServices()和AddRealNotificationServices()然后在Program.cs里按環(huán)境調(diào)用。6. 調(diào)試與性能IEnumerable 注入、驗(yàn)證作用域與避免頻繁解析依賴注入用多了你會(huì)發(fā)現(xiàn)大部分問(wèn)題不是“不會(huì)用”而是“出問(wèn)題時(shí)不知道怎么查”。這一章我聊聊調(diào)試和性能優(yōu)化的一些實(shí)操經(jīng)驗(yàn)。6.1 所有注冊(cè)的服務(wù)都能通過(guò)IEnumerableT獲取在 ASP.NET Core 的容器里如果你注冊(cè)了多個(gè)IFoo的實(shí)現(xiàn)那么注入IEnumerableIFoo時(shí)會(huì)拿到所有注冊(cè)的實(shí)例順序按照注冊(cè)順序。這個(gè)特性有兩個(gè)常見的用途實(shí)現(xiàn)某種“策略集合”循環(huán)調(diào)用每個(gè)策略。典型的例子是多個(gè)校驗(yàn)器按順序執(zhí)行直到有一個(gè)不通過(guò)。做插件化架構(gòu)時(shí)動(dòng)態(tài)加載程序集里所有實(shí)現(xiàn)了某個(gè)接口的類然后統(tǒng)一注冊(cè)統(tǒng)一解析。我見過(guò)不少人為了拿到多個(gè)實(shí)現(xiàn)自己維護(hù)一個(gè)列表清單然后在注冊(cè)時(shí)逐個(gè) new。其實(shí)完全可以依賴容器本身用IEnumerableT注入。但注意這個(gè)特性和“按名字獲取具體實(shí)現(xiàn)”不一樣。如果你需要“根據(jù) key 精確獲取某一個(gè)”還是得回到工廠模式或字典映射。6.2 啟動(dòng)時(shí)驗(yàn)證作用域把問(wèn)題暴露在啟動(dòng)階段而不是請(qǐng)求階段ASP.NET Core 提供了ValidateScopes選項(xiàng)用于在啟動(dòng)時(shí)檢測(cè)“從根容器解析 Scoped 服務(wù)”這類錯(cuò)誤。開發(fā)環(huán)境下默認(rèn)是開啟的生產(chǎn)環(huán)境默認(rèn)是關(guān)閉的出于性能考慮。但如果你吃了“Singleton 依賴 Scoped”的虧建議在生產(chǎn)環(huán)境也開啟這個(gè)驗(yàn)證代價(jià)只是啟動(dòng)時(shí)稍微多做一點(diǎn)檢查但能在部署早期就把問(wèn)題暴露出來(lái)。在 .NET 6 的程序里可以這樣配置var builder WebApplication.CreateBuilder(args); builder.Host.UseDefaultServiceProvider(options { options.ValidateScopes true; // 驗(yàn)證作用域 options.ValidateOnBuild true; // 啟動(dòng)時(shí)構(gòu)建驗(yàn)證 });ValidateOnBuild更狠一點(diǎn)會(huì)在容器構(gòu)建完成后立即嘗試解析所有注冊(cè)的服務(wù)檢查構(gòu)造函數(shù)依賴是否都能滿足、有沒(méi)有明顯的循環(huán)依賴。這個(gè)對(duì)大型項(xiàng)目特別友好因?yàn)楹芏鄦?wèn)題不用等到運(yùn)行時(shí)請(qǐng)求才暴露。我記得有一次在重構(gòu)一個(gè)老項(xiàng)目把幾個(gè)服務(wù)從靜態(tài)類改成 DI 注冊(cè)結(jié)果啟動(dòng)到一個(gè)數(shù)據(jù)庫(kù)服務(wù)時(shí)總是報(bào)“Unable to resolve service”錯(cuò)誤。打開ValidateOnBuild后啟動(dòng)日志直接把缺失依賴的服務(wù)名打印得清清楚楚我順著依賴鏈一個(gè)個(gè)補(bǔ)注冊(cè)十分鐘就搞定了。以前要是靠跑起來(lái)之后某個(gè)請(qǐng)求才觸發(fā)那排查時(shí)間得多花好幾倍。6.3 性能陷阱頻繁從 IServiceProvider 解析不是免費(fèi)的IServiceProvider.GetService()的解析成本雖然不算高但也絕不是零成本。在熱路徑比如循環(huán)、高頻接口調(diào)用里反復(fù)解析服務(wù)會(huì)造成可感知的 CPU 開銷。我見過(guò)一個(gè)性能問(wèn)題某個(gè)中間件在每次請(qǐng)求里用了十幾次RequestServices.GetService()雖然每次只有微秒級(jí)消耗但疊加到每秒幾萬(wàn)請(qǐng)求的規(guī)模上浪費(fèi)就很明顯了。最直接的優(yōu)化方式是把服務(wù)依賴挪到構(gòu)造函數(shù)里注入而不是在方法內(nèi)部每次解析。對(duì)于必須動(dòng)態(tài)解析的場(chǎng)景比如策略模式、選路邏輯可以將解析結(jié)果緩存到一個(gè)局部變量中循環(huán)外解析循環(huán)內(nèi)復(fù)用。6.4 陷阱容器釋放順序與 IDisposable服務(wù)如果實(shí)現(xiàn)了IDisposable容器負(fù)責(zé)在生命周期結(jié)束時(shí)釋放它。Singleton 在應(yīng)用停止時(shí)釋放Scoped 在請(qǐng)求結(jié)束時(shí)釋放Transient 在解析者釋放時(shí)釋放如果解析者沒(méi)有釋放容器也會(huì)在 Scope 釋放時(shí)統(tǒng)一釋放。關(guān)于這塊有個(gè)容易被誤解的點(diǎn)如果你手動(dòng)new出來(lái)一個(gè)服務(wù)沒(méi)有經(jīng)過(guò)容器容器是不知道也不負(fù)責(zé)釋放的你需要自己管理它的生命周期。還有一個(gè)小坑如果你用工廠注冊(cè)AddTransientIFoo(sp new Foo())返回一個(gè)實(shí)現(xiàn)了IDisposable的對(duì)象容器會(huì)跟蹤并釋放它前提是它是在容器解析時(shí)創(chuàng)建的。如果你的工廠返回的是一個(gè)已經(jīng)存在的單例比如靜態(tài)實(shí)例容器可能會(huì)重復(fù)釋放同一個(gè)對(duì)象這時(shí)候要格外小心。經(jīng)驗(yàn)是讓容器管理生命周期不要在工廠里返回自己管理生命周期的“外來(lái)對(duì)象”除非你確認(rèn)不會(huì)出現(xiàn)重復(fù)釋放問(wèn)題。7. 架構(gòu)層面的實(shí)踐接口、模塊化注冊(cè)與可測(cè)試性依賴注入的最終勝利不在于“會(huì)用”而在于“用得順手”。我自己在架構(gòu)層面有幾條心得分享給大家。7.1 每個(gè)項(xiàng)目都按模塊拆分注冊(cè)擴(kuò)展方法我參與過(guò)的項(xiàng)目中最容易失控的是那個(gè)巨無(wú)霸Program.cs或Startup.cs。幾十個(gè)AddSomething()擠在一起誰(shuí)也不敢動(dòng)改一行都心驚膽戰(zhàn)。后來(lái)我養(yǎng)成了一個(gè)習(xí)慣每個(gè)業(yè)務(wù)模塊自己寫一個(gè)服務(wù)注冊(cè)擴(kuò)展方法內(nèi)部只負(fù)責(zé)本模塊依賴的服務(wù)然后在Program.cs里調(diào)用它。舉個(gè)例子一個(gè)“訂單模塊”可以有一個(gè)public static class OrderServiceCollectionExtensions { public static IServiceCollection AddOrderModule(this IServiceCollection services) { services.AddScopedIOrderRepository, SqlOrderRepository(); services.AddScopedIOrderService, OrderService(); services.AddScopedIOrderDomainEventHandler, OrderDomainEventHandler(); return services; } }Program.cs里三五行就搞定builder.Services.AddInfrastructureModule(); builder.Services.AddOrderModule(); builder.Services.AddPaymentModule();這樣每個(gè)模塊的依賴關(guān)系集中在模塊自己的擴(kuò)展方法里找問(wèn)題的時(shí)候直接進(jìn)模塊文件不用在啟動(dòng)文件里撈針。配合上模塊化項(xiàng)目的層次結(jié)構(gòu)應(yīng)用層、領(lǐng)域?qū)印⒒A(chǔ)設(shè)施層、表現(xiàn)層每一層的 DI 注冊(cè)職責(zé)也能被清晰劃分。7.2 用容器做依賴注入但也別把一切都扔進(jìn)容器有一類東西我不建議放容器里。比如配置對(duì)象直接用IOptionsT、靜態(tài)工具類如MathHelper、簡(jiǎn)單的數(shù)據(jù)傳輸對(duì)象DTO。容器存在的意義是管理復(fù)雜依賴關(guān)系和生命周期如果什么東西都硬塞進(jìn)容器解析鏈會(huì)越來(lái)越長(zhǎng)性能下降排查也麻煩。還有一類需要小心的是“長(zhǎng)期存在的服務(wù)”和“短期請(qǐng)求”混合的情況。比如 Singleton 的緩存服務(wù)里不小心引用了 Scoped 的DbContext這就是架構(gòu)層面的錯(cuò)誤。我給出的建議很簡(jiǎn)單畫一條依賴規(guī)則——Singleton 只能依賴 SingletonScoped 可以依賴 Scoped 和 SingletonTransient 可以依賴任意生命周期。寫進(jìn)團(tuán)隊(duì)規(guī)范當(dāng)作評(píng)審時(shí)的關(guān)注點(diǎn)。7.3 依賴注入如何讓測(cè)試變得更簡(jiǎn)單依賴注入最大的工程紅利是“可測(cè)試性”。因?yàn)橐粋€(gè)類的依賴都是通過(guò)接口注進(jìn)來(lái)的測(cè)試時(shí)你可以隨手替換成假的實(shí)現(xiàn)不需要啟動(dòng)整個(gè)應(yīng)用不需要碰數(shù)據(jù)庫(kù)不需要真實(shí)發(fā)郵件。我寫單元測(cè)試時(shí)的做法是[Fact] public async Task GetWeatherAsync_WhenCityIsEmpty_ThrowsArgumentException() { var weatherService new WeatherService( Mock.OfIWeatherRepository(), Mock.OfICacheService()); await Assert.ThrowsAsyncArgumentException( () weatherService.GetWeatherAsync()); }這里每個(gè)依賴都能用 mock 對(duì)象替代測(cè)試用例短小明確。如果沒(méi)有依賴注入你可能要花大力氣構(gòu)造WeatherService的內(nèi)部依賴甚至要起一個(gè)完整的服務(wù)宿主測(cè)試效率和可維護(hù)性都差很多。7.4 依賴注入與模塊化邊界別讓容器變成“上帝對(duì)象”有一種反模式是為了讓某個(gè)服務(wù)在任何地方都能拿到把它注冊(cè)成 Singleton然后在幾乎每個(gè)類里注入它。這會(huì)造成隱式的全局依賴代碼之間通過(guò)這個(gè)“上帝對(duì)象”互相通信模塊邊界名存實(shí)亡。我在一些老項(xiàng)目里見過(guò)這種現(xiàn)象整改起來(lái)特別痛苦。正確的做法是依賴關(guān)系要顯式地通過(guò)構(gòu)造函數(shù)表達(dá)出來(lái)。如果一個(gè)類需要“當(dāng)前用戶信息”不要讓它自己去全局容器里拿而是讓調(diào)用方把用戶信息顯式傳進(jìn)來(lái)。容器只用來(lái)組裝那些“真正需要容器管理的服務(wù)”不要用它作為傳遞參數(shù)的通道。這一點(diǎn)做得好模塊邊界才能保持清晰。8. 那些坑循環(huán)依賴、作用域失控與我沒(méi)能早發(fā)現(xiàn)的錯(cuò)誤最后一個(gè)大章節(jié)聊幾個(gè)實(shí)際項(xiàng)目中經(jīng)常踩的坑。這些坑每個(gè)我都見過(guò)或者親身體驗(yàn)過(guò)希望你們能提前避雷。8.1 循環(huán)依賴兩個(gè)服務(wù)互相引用彼此依賴注入最經(jīng)典的報(bào)錯(cuò)之一A依賴BB又依賴A。容器在嘗試解析時(shí)會(huì)發(fā)現(xiàn)依賴鏈成了一個(gè)環(huán)然后拋出異常。解決辦法一般有三種重構(gòu)拆分把 A 和 B 之間互相依賴的那部分邏輯抽出來(lái)放到第三個(gè)類 C 里A 和 B 都依賴 C循環(huán)自然解除。這是最徹底的方案也是我最推薦的方式。改變生命周期如果 A 和 B 都是 Transient改成其中一個(gè)為 Singleton 或 Scoped有時(shí)能繞過(guò)構(gòu)建循環(huán)的問(wèn)題。但這治標(biāo)不治本潛在風(fēng)險(xiǎn)仍然在。延遲解析某個(gè)服務(wù)在真正用到時(shí)才去容器解析通過(guò)注入IServiceProvider而不是在構(gòu)造函數(shù)里直接依賴?？梢越鉀Q問(wèn)題但代價(jià)是“依賴關(guān)系變隱式了”而且會(huì)破壞構(gòu)造函數(shù)注入的清晰性。我的經(jīng)驗(yàn)是遇到循環(huán)依賴先停下來(lái)想想設(shè)計(jì)問(wèn)題而不是急著找 hack。循環(huán)依賴通常意味著職責(zé)邊界劃分不當(dāng)。重構(gòu)雖然工作量大一點(diǎn)但以后維護(hù)的舒適度完全值得。8.2 作用域失控一個(gè) Scoped 服務(wù)被 Singleton 持有了這個(gè)坑我在生命周期章節(jié)提過(guò)但值得再具體演示一下。假設(shè)你有一個(gè)ICacheService注冊(cè)成了 Singleton而它內(nèi)部注入了IBillingRepositoryScoped。容器啟動(dòng)時(shí)不會(huì)立刻檢測(cè)到錯(cuò)誤除非開啟了ValidateOnBuild但等到某個(gè)請(qǐng)求使用了這個(gè)緩存服務(wù)運(yùn)行時(shí)就會(huì)拋出異常。這類問(wèn)題最陰險(xiǎn)的地方是它不一定在啟動(dòng)階段出現(xiàn)而是取決于哪個(gè)請(qǐng)求先觸發(fā)。A 客戶端的請(qǐng)求觸發(fā)了一切正常B 客戶端的請(qǐng)求觸發(fā)了直接 500。我見過(guò)一個(gè)項(xiàng)目因?yàn)檫@個(gè)原因偶發(fā)崩潰排查了好久才定位到這層關(guān)系。最好的防線就是我在前面說(shuō)的同一個(gè)服務(wù)生命周期統(tǒng)一Singleton 依賴鏈上全部是 Singleton在開發(fā)環(huán)境開啟服務(wù)作用域驗(yàn)證。這三條做到了這類坑基本能全部躲掉。8.3 過(guò)度注入構(gòu)造函數(shù)動(dòng)不動(dòng)就七八個(gè)參數(shù)如果一個(gè)服務(wù)類構(gòu)造函數(shù)里要注入七八個(gè)東西這個(gè)類八成違背了“單一職責(zé)原則”。七八個(gè)依賴意味著它同時(shí)在做好幾件事。我見過(guò)最夸張的某個(gè)服務(wù)構(gòu)造函數(shù)里塞了 12 個(gè)依賴每次修改都要傳新參數(shù)測(cè)試時(shí) mock 也要寫 12 行。重構(gòu)思路是拆類把數(shù)據(jù)庫(kù)訪問(wèn)拆出去、把通知拆出去、把緩存拆出去然后用門面模式或組合模式把幾個(gè)小服務(wù)組合起來(lái)。依賴注入容器擅長(zhǎng)組裝所以“很多小對(duì)象組合成一個(gè)大對(duì)象”是合理的但“一個(gè)大對(duì)象硬吞進(jìn)無(wú)數(shù)依賴”是不合理的。8.4 忘記釋放 scope 資源在手動(dòng)創(chuàng)建 Scope 的場(chǎng)景里后臺(tái)任務(wù)、控制臺(tái)應(yīng)用如果忘記using釋放 ScopeScoped 服務(wù)里創(chuàng)建的DbContext、HTTP 客戶端連接等資源就會(huì)一直占著內(nèi)存時(shí)間長(zhǎng)了可能引發(fā)連接池耗盡、內(nèi)存泄漏。我給自己定的習(xí)慣是所有手動(dòng)創(chuàng)建的 Scope 一律用using或await using包起來(lái)確保離開代碼塊就釋放。哪怕只是解析一個(gè)不痛不癢的小服務(wù)也養(yǎng)成這個(gè)習(xí)慣免得哪天換成DbContext時(shí)踩雷。8.5 啟動(dòng)時(shí)解析 Scoped 服務(wù)的“想當(dāng)然”錯(cuò)誤前面說(shuō)過(guò)在Program.cs或Startup.cs里直接解析 Scoped 服務(wù)是個(gè)常見的坑。比如有人想在啟動(dòng)時(shí)初始化 admin 用戶var adminService app.Services.GetRequiredServiceIAdminService(); adminService.Initialize();如果IAdminService注冊(cè)的是 Scoped這段代碼會(huì)直接報(bào)錯(cuò)未開啟ValidateScopes時(shí)也可能不報(bào)錯(cuò)但行為不保證。正確寫法using (var scope app.Services.CreateScope()) { var adminService scope.ServiceProvider.GetRequiredServiceIAdminService(); adminService.Initialize(); }這個(gè)“手動(dòng)開 Scope 解析服務(wù)”的模式在 .NET 6 的WebApplication環(huán)境里尤其常見因?yàn)镻rogram.cs里寫啟動(dòng)邏輯的人很多。記住一條根容器的ApplicationServices是用來(lái)解析 Singleton 和通過(guò)工廠解析服務(wù)的不是給你解析 Scoped 服務(wù)的。9. 我的推薦實(shí)踐從開發(fā)到生產(chǎn)環(huán)境一路穩(wěn)最后我給出一份我在實(shí)際項(xiàng)目里會(huì)用的“依賴注入實(shí)踐清單”。這些條不是什么金科玉律但經(jīng)過(guò)多個(gè)項(xiàng)目的錘煉確實(shí)能幫我少踩很多坑。注冊(cè)入口盡量集中在模塊擴(kuò)展方法里不要在Program.cs里散落大量注冊(cè)代碼。每個(gè)模塊對(duì)自己負(fù)責(zé)注冊(cè)代碼的查找成本極大降低。生命周期統(tǒng)一且顯式同一個(gè)服務(wù)類型只注冊(cè)一種生命周期。注冊(cè) Unity 時(shí)團(tuán)隊(duì)規(guī)范里寫明“所有服務(wù)必須顯式指定生命周期”不允許使用默認(rèn)的自動(dòng)注冊(cè)工具把一切都變成 Transient 或 Singleton。在開發(fā)環(huán)境和生產(chǎn)環(huán)境都開啟ValidateScopes。雖然生產(chǎn)環(huán)境有一些性能開銷但換來(lái)的是早期發(fā)現(xiàn)生命周期錯(cuò)誤。如果對(duì)性能極度敏感可以在生產(chǎn)環(huán)境關(guān)閉但要保證測(cè)試和預(yù)發(fā)布環(huán)境開啟。堅(jiān)持構(gòu)造函數(shù)注入避免屬性注入和服務(wù)定位器模式。構(gòu)造函數(shù)注入最顯式依賴關(guān)系一目了然。雖然屬性注入寫起來(lái)更少但“依賴關(guān)系隱式化”后代碼的可讀性和可測(cè)性會(huì)變差。使用IOptionsT來(lái)管理配置不要直接把配置對(duì)象注冊(cè)成 Singleton。這樣配置的刷新、熱更新才有標(biāo)準(zhǔn)支持測(cè)試時(shí)替換配置也更靈活。對(duì)資源型服務(wù)比如 DbContext、數(shù)據(jù)庫(kù)連接優(yōu)先使用 Scoped并且確保在請(qǐng)求管道或手動(dòng) Scope 里使用。如果需要在后臺(tái)任務(wù)里使用就手動(dòng)創(chuàng)建并釋放 Scope。依賴方向只允許單向流動(dòng)接口定義在一個(gè)模塊實(shí)現(xiàn)放在基礎(chǔ)設(shè)施層應(yīng)用層只依賴接口。這樣 Web API、后臺(tái)任務(wù)、測(cè)試都能共用同一個(gè)接口層模塊之間的耦合被降到最低。定期做依賴關(guān)系審計(jì)可以寫一個(gè)簡(jiǎn)單的構(gòu)建腳本在 CI 階段把服務(wù)注冊(cè)列表輸出到日志里看看有沒(méi)有某個(gè)模塊的注冊(cè)依賴異常。這個(gè)對(duì)團(tuán)隊(duì)協(xié)作特別有幫助。我可以坦誠(chéng)地說(shuō)依賴注入這套機(jī)制我自己從“會(huì)用”到“覺得香”經(jīng)歷了挺長(zhǎng)時(shí)間。很多經(jīng)驗(yàn)也是靠踩坑換來(lái)的——特別是那幾個(gè)生命周期相關(guān)的坑我至今記憶猶新。希望這篇長(zhǎng)文能幫你把 ASP.NET Core 依賴注入從“知道概念”推向“理解本質(zhì)”以后在項(xiàng)目里用它建模、設(shè)計(jì)服務(wù)邊界、排查疑難問(wèn)題的時(shí)候能更有底氣。