2. 程式人生 > >如何在 asp.net core 3.x 的 startup.cs 檔案中獲取注入的服務

如何在 asp.net core 3.x 的 startup.cs 檔案中獲取注入的服務

阿新 • • 發佈：2020-06-29
### 一、前言 從 18 年開始接觸 .NET Core 開始，在私底下、工作中也開始慢慢從傳統的 mvc 前後端一把梭，開始轉向 web api + vue，之前自己有個半成品的 asp.net core 2.2 的專案模板，最近幾個月的時間，私下除了學習 Angular 也在對這個模板基於 asp.net core 3.1 進行慢慢補齊功能 因為涉及到底層框架大版本升級，由於某些 breaking changes 必定會造成之前的某些寫法沒辦法繼續使用，趁著端午節假期，在改造模板時，發現沒辦法通過建構函式注入的形式在 `Startup` 檔案中注入某些我需要的服務了，因此本篇文章主要介紹如何在 asp.net core 3.x 的 startup 檔案中獲取注入的服務 ### 二、Step by Step #### 2.1、問題案例 這個問題的發現源於我需要改造模型驗證失敗時返回的錯誤資訊，如果你有嘗試的話，在 3.x 版本中你會發現在 `Startup` 類中，我們沒辦法通過建構函式注入的方式再注入任何其它的服務了，這裡僅以我的程式碼中需要解決的這個問題作為案例 在定義介面時，為了降低後期調整的複雜度，在接收引數時，一般會將引數包裝成一個 dto 物件（data transfer object - 資料傳輸物件），不管是提交資料，還是查詢資料，對於這個 dto 中的某些屬性，都會存在一定的卡控，例如 xxx 欄位不能為空了，xxx 欄位的長度不能超過 30 而在 asp.net core 中，因為會自動進行模型驗證，當不符合 dto 中的屬性要求時，介面會自動返回錯誤資訊，預設的返回資訊如下圖所示 ![模型驗證失敗](https://img2020.cnblogs.com/blog/1310859/202006/1310859-20200627104652359-1243794665.png) 可以看到，因為這裡其實是按照 rfc7231這個 RFC 協議返回的錯誤資訊，這個並不符合我的要求，因此這裡我需要改寫這個返回的錯誤資訊 自定義 asp.net core 的模型驗證錯誤資訊方法有很多種，我的實現方法如下，因為我需要記錄請求的標識 Id 和錯誤日誌，所以這裡我需要將 `ILogger` 和 `IHttpContextAccessor` 注入到 `Startup` 類中 ```csharp /// /// 修改模型驗證錯誤返回資訊 /// /// 服務容器集合 /// 日誌記錄例項 /// /// public static IServiceCollection AddCustomInvalidModelState(this IServiceCollection services, ILogger logger, IHttpContextAccessor httpContextAccessor) { services.Configure(options => { options.InvalidModelStateResponseFactory = actionContext => { // 獲取驗證不通過的欄位資訊 // var errors = actionContext.ModelState.Where(e => e.Value.Errors.Count > 0) .Select(e => new ApiErrorDto { Title = "請求引數不符合欄位格式要求", Message = e.Value.Errors.FirstOrDefault()?.ErrorMessage }).ToList(); var result = new ApiReturnDto { TraceId = httpContextAccessor.HttpContext.TraceIdentifier, Status = false, Error = errors }; logger.LogError($"介面請求引數格式錯誤: {JsonConvert.SerializeObject(result)}"); return new BadRequestObjectResult(result); }; }); return services; } ``` 在 asp.net core 2.x 版本中，你完全可以像在別的類中採用建構函式注入的方式一樣直接注入使用 ```csharp public class Startup { /// /// 日誌記錄例項 ///
private readonly ILogger _logger; /// /// Http 請求例項 /// private readonly IHttpContextAccessor _httpContextAccessor; /// /// ctor /// /// /// /// public Startup(IConfiguration configuration, ILogger logger, IHttpContextAccessor httpContextAccessor) { Configuration = configuration ?? throw new ArgumentNullException(nameof(configuration)); _logger = logger ?? throw new ArgumentNullException(nameof(logger)); _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor)); } /// /// 配置例項 ///
public IConfiguration Configuration { get; } /// /// This method gets called by the runtime. Use this method to add services to the container. /// public void ConfigureServices(IServiceCollection services) { //注入的其它服務 // 返回自定義的模型驗證錯誤資訊 services.AddCustomInvalidModelState(_logger, _httpContextAccessor); } } ``` 但是當你直接遷移到 asp.net core 3.x 版本後，你會發現程式會報如下的錯誤，很常見的一個依賴注入的錯誤，源頭直指我們通過建構函式注入的 `ILogger`、`IHttpContextAccessor` 介面 ![遷移之後的報錯資訊](https://img2020.cnblogs.com/blog/1310859/202006/1310859-20200627104709016-1627294717.png) #### 2.2、解決方法 ##### 根本原因 通過查閱 stackoverflow 發現了這樣的一個問題：[How do I write logs from within Startup.cs](https://stackoverflow.com/questions/41287648/how-do-i-write-logs-from-within-startup-cs)，在最高讚的回答中提到了在泛型主機（GenericHostBuilder）中，沒辦法注入除 `IConfiguration` 之外的任何服務到 `Startup`類中，而泛型主機則是在 asp.net core 3.0 中新增的功能 查了下升級日誌，從中可以看到，在泛型主機中， `Startup` 類的建構函式注入只支援 `IHostEnvironment`、 `IWebHostEnvironment`、`IConfiguration` ，嗯，不好好看別人文件的鍋 ![泛型主機](https://img2020.cnblogs.com/blog/1310859/202006/1310859-20200627104721290-1080090326.png) 為什麼使用 `WebHostBuilder`可以，換成 `GenericHostBuilder` 就不行了呢 按照正常的邏輯來說，對於一個 asp.net core 應用，原則上來說只有有一個根級（root）的依賴注入容器，但是因為我們在 `Startup` 類中通過建構函式注入的形式注入服務時，告訴程式了我需要這個服務的例項，從而導致在構建 WebHost 時存在了一個單獨的容器，並且這個容器只包含了我們需要使用到的服務資訊，之後，因為會建立了一個包含完整服務的依賴注入容器，這裡就會存在一個服務哪怕是單例的也可能會存在註冊兩次的問題，這無疑有些不太合乎規範 在推行泛型主機之後，嚴格控制了只會存在一個依賴注入容器，而所有的服務都是在 `Startup.ConfigureServices` 方法執行完成後才會註冊到依賴注入容器中，因此沒辦法像之前一樣在根容器註冊完成之前通過建構函式注入的形式使用 ##### 解決方案 如果你需要在 `Startup.Configure` 方法中使用自定義的服務，因為這裡已經完成了各種服務的註冊，和之前一樣，我們直接在方法簽名中包含需要使用到的服務即可 ```csharp public void Configure(IApplicationBuilder app, IHostEnvironment env, ILogger logger) { logger.LogInformation("在 Configure 中使用自定義的服務"); } ``` 如果你需要在 `Startup.ConfigureServices` 中使用的話，則需要換一種方法 最簡單的方法，直接替換泛型主機為原來的 `WebHostBuilder`，這樣就可以直接在 `Startup` 類中注入各種服務介面了，不過，考慮到這一改動其實是在開倒車，所以這裡不推薦採用這種方法 既然沒辦法正向通過依賴注入容器來自動建立我們需要的服務例項，是不是可以通過服務容器，手動去獲取我們需要的服務，也就是被稱為服務定位（`Service Locator`）的方式來獲取例項 當然，這似乎與依賴注入的思想相左，對於依賴注入來說，我們將所有需要使用的服務定義好，在應用啟動前完成註冊，之後在使用時由依賴注入容器提供服務的例項即可，而服務定位則是我們已經知道存在這個服務了，從容器中獲取出來然後由自己手動的建立例項 雖然服務定位是一種反模式，但是在某些情況下，我們又不得不採用 這裡對於本篇文章開篇中需要解決的問題，我也是採用服務定位的方式，通過構建一個 ServiceProvider 之後，手動的從容器中獲取需要使用的服務例項，調整後的程式碼如下 ```csharp /// /// 新增自定義模型驗證失敗時返回的錯誤資訊 ///
/// 服務容器集合 /// public static IServiceCollection AddCustomInvalidModelState(this IServiceCollection services) { // 構建一個服務的提供程式 var provider = services.BuildServiceProvider(); // 獲取需要使用的服務例項 // var logger = provider.GetRequiredService>(); var httpContextAccessor = provider.GetRequiredService(); services.Configure(options => { options.InvalidModelStateResponseFactory = actionContext => { // 獲取失敗資訊 // var errors = actionContext.ModelState.Where(e => e.Value.Errors.Count > 0) .Select(e => new ApiErrorMessageDto { Title = "Request parameters do not meet the field requirements", Message = e.Value.Errors.FirstOrDefault()?.ErrorMessage }).ToList(); var result = new ApiResponseDto { TraceId = httpContextAccessor.HttpContext.TraceIdentifier, Status = false, Error = errors }; logger.LogError($"介面請求引數格式錯誤: {JsonSerializer.Serialize(result)}"); return new BadRequestObjectResult(result); }; }); return services; } ``` 對於配置一些需要基於某些服務的服務，這裡也可以通過委託的形式獲取到需要使用的服務例項，示例程式碼如下 ```csharp public void ConfigureServices(IServiceCollection services) { services.AddSingleton((container) => { var logger = container.GetRequiredService>(); return new MyService { Logger = logger }; }); } ``` ### 三、參考資料 - [ASP.NET Core 3.0 的新增功能](https://docs.microsoft.com/zh-cn/aspnet/core/release-notes/aspnetcore-3.0?view=aspnetcore-3.1) - [Generic Host restricts Startup constructor injection](https://github.com/aspnet/Announcements/issues/353) - [依賴注入模式](https://www.cnblogs.com/artech/p/net-core-di-03.html) - [Avoiding Startup service injection in ASP.NET Core 3](https://andrewlock.net/avoiding-startup-service-injection-in-asp-net-core-3/)

相關推薦

如何在 asp.net core 3.x 的 startup.cs 檔案中獲取注入的服務

### 一、前言 從 18 年開始接觸 .NET Core 開始，在私底下、工作中也開始慢慢從傳統的 mvc 前後端一把梭，開始轉向 web api + vue，之前自己有個半成品的 asp.net core 2.2 的專案模板，最近幾個月的時間，私下除了學習 Angular 也在對這個模板基於 asp.n

ASP.NET Core 3.x 併發限制

前言 Microsoft.AspNetCore.ConcurrencyLimiter AspNetCore3.0後增加的,用於傳入的請求進行排隊處理,避免執行緒池的不足. 我們日常開發中可能常做的給某web伺服器配置連線數以及,請求佇列大小,那麼今天我們看看如何在通過中介軟體形式實現一個併發量以及佇列長度

使用ASP.NET Core 3.x 構建 RESTful API - 3.3 狀態碼、錯誤/故障、ProblemDetails

HTTP狀態碼 HTTP狀態碼會告訴API的消費者以下事情：  請求是否執行成功了  如果請求失敗了，那麼誰為它負責    HTTP的狀態碼有很多，但是Web API不一定需要支援所有的狀態碼。HTTP狀態碼一共分為5個級別： 

asp.net core 3.x Endpoint終結點路由1-基本介紹和使用

前言 我是從.net 4.5直接跳到.net core 3.x的，感覺asp.net這套東西最初是從4.5中的owin形成的。目前官方文件重點是講路由，沒有特別說明與傳統路由的區別，本篇主要介紹終結點路由的相關概念和如何使用，不會詳細介紹路由，這個參考官方文件就ok了。如果將來有機會研究到底層再深度剖析。

使用ASP.NET Core 3.x 構建 RESTful API - 4.3 HTTP 方法的安全性和冪等性

什麼樣的HTTP方法是安全的？  如果一個方法不會改變資源的表述，那麼這個方法就被認為是安全的。  例如 HTTP GET 和 HTTP HEAD 就被認為是安全的，但需要注意的是，這並不意味著執行GET請求就不會引起其它的資

asp.net core 3.x 通用主機原理及使用

一、前言 只是講asp.net core 3.x通用主機的大致原理，這些東西是通過檢視原始碼以及自己根據經驗總結得來的，在文章中不會深入原始碼，因為個人覺得懂原理就曉得擴充套件點，後期碰到有需求的時候再仔細去研究原始碼也不遲。閱讀前你應該先去了解下（推薦部落格園老A的部落格）： asp.net cor

asp.net core 3.x 模組化開發之HostingStartup

我們希望將一個專案（dll）看做一個模組/外掛，一個模組往往需要在應用啟動時做一些初始化工作，比如向IOC容器新增一些服務，為應用配置物件新增自己的資料來源；也希望在應用關閉時做一些收尾工作，asp.net core為我們提供了這種機制，先來看看如何使用，再講講原理。 如何使用？ 1、建立asp.net

asp.net core 3.x 通用主機是如何承載asp.net core的-上

一、前言 上一篇《asp.net core 3.x 通用主機原理及使用》扯了下3.x中的通用主機，剛好有哥們寫了篇《.NET Core 3.1和WorkerServices構建Windows服務》可以當做通用主機的案例來看。本篇主要聊下asp.net core 3.x中是如何使用通用主機來承載asp.net

初探ASP.NET Core 3.x (1) - 關於ASP.NET

本文地址：https://www.cnblogs.com/oberon-zjt0806/p/12209930.html I 什麼是ASP.NET Core II 我該如何獲取ASP.NET呢 II.1 使用Visual Studio進行整合安裝和開發 II.2 手動安裝 III 專案構建 IV 專案

初探ASP.NET Core 3.x (3) - Web的運作流程和ASP.NET Core的運作結構

本文地址：https://www.cnblogs.com/oberon-zjt0806/p/12215717.html 注意：本篇大量地使用了mermaid繪製圖表，載入需要較長的時間，請見諒 [TOC] O 前請提要 在第1期中，我們通過一個簡單的過程構建了一個ASP.NET的初始專案，當然，實際上

初探ASP.NET Core 3.x (4) - 專案的重要組成

目錄 O 前請提要 I 啟動部分 I.1 Program類 I.2 Startup類 I.2.1 這個類幹什麼呢？？ I.2.2 特徵？？ I

asp.net core 3.x 身份驗證-1涉及到的概念

前言 從本篇開始將圍繞asp.net core身份驗證寫個小系列，希望你看完本系列後，腦子裡對asp.net core的身份驗證原理有個大致印象。至於身份驗證是啥？與授權有啥聯絡？就不介紹了，太囉嗦。你如果不曉得，自己去搜搜吧。我的學習思路是詳細看原始碼 > 總結得出一個巨集觀上的印象 + 如何使用。如

gRPC in ASP.NET Core 3.x -- Protocol Buffer（2）Go語言的例子（下）

第一篇文章（大約半年前寫的）：https://www.cnblogs.com/cgzl/p/11246324.html gRPC in ASP.NET Core 3.x -- Protocol Buffer（2）Go語言的例子（上）  接著上一篇文章。   寫入到JSON 首先寫一個fun

asp.net core 3.x 身份驗證-2啟動階段的配置

註冊服務、配置選項、新增身份驗證方案 在Startup.ConfigureServices執行services.AddAuthentication() 註冊如下服務（便於理解省略了部分輔助服務）： services.TryAddScoped<IAuthenticationService, Authen

asp.net core 3.x 身份驗證-3cookie身份驗證原理

概述 上兩篇（asp.net core 3.x 身份驗證-1涉及到的概念、asp.net core 3.x 身份驗證-2啟動階段的配置）介紹了身份驗證相關概念以及啟動階段的配置，本篇以cookie身份驗證為例來大致說明asp.net core中的身份驗證原理。如果我們的應用只考慮瀏覽器使用，且不考慮前後端分離

asp.net core 3.x 授權中的概念

前言 預計是通過三篇來將清楚asp.net core 3.x中的授權：1、基本概念介紹；2、asp.net core 3.x中授權的預設流程；3、擴充套件。 在完全沒有概念的情況下無論是看官方文件還是原始碼都暈乎乎的，希望本文能幫到你。不過我也是看原始碼結合官方文件看的，可能有些地方理解不對，所以只作為參考。

asp.net core 3.x 授權預設流程

一、前言 接上一篇《asp.net core 3.x 授權中的概念》，本篇看看asp.net core預設授權的流程。從兩個方面來看整個授權系統是怎麼執行的：啟動階段的配置、請求階段中介軟體的處理流程。 由於asp.net core 3.x目前使用終結點路由，因此授權框架可以用於所有asp.net web專案

ASP.NET Core 3.x 中介軟體流程與路由體系

中介軟體分類   ASP.NET Core 中介軟體的配置方法可以分為以上三種，對應的Helper方法分別是：Run(), Use(), Map()。 Run()，使用Run呼叫中介軟體的時候，會直接返回一個響應，所以後續的中介軟體將不會被執行了。 Use()，它會對請求做一些工作或處理，例如

ASP.NET Core 3.x API版本控制

# 前言 一般來說需要更改我們API的時候才考慮版本控制，但是我覺得我們不應該等到那時候來實現它，我們應該有一個版本策略從我們應用程式開發時就開始制定好我們的策略，我們一直遵循著這個策略進行開發。 我們其實可以通過多種方式進行實現我們API版本的控制，其實對於版本控制沒有最好的方式，這完全取決於我們面向的

ASP.NET Core 3.x控制IHostedService啟動順序淺探

想寫好中介軟體，這是基礎。   一、前言 今天這個內容，基於於ASP.NET Core 3.x。 從3.x開始，ASP.NET Core使用了通用主機模式。它將WebHostBuilder放到了通用的IHost之上，這樣可以確保Kestrel可以執行在IHostedService中。 我們今天就來研究一