Разрешить службу в действии настройки HttpContext

Я предполагаю, что на самом деле вопрос заключается в том, как получить доступ к конфигурации или любой другой службе при регистрации типизированного HttpClient и HttpContext (контекст конкретного HTTP-запроса) не имеет значения.

ОБНОВИТЬ В .NET Core 2.1 AddHttpClient не имеет перегрузки с параметрами типа два и aIServiceCollection, несмотря на то, что показано в документации. Та же работа выполняется путем вызова ConfigureHttpClient после AddHttpClient.

services
    .AddHttpClient<TTypedHttpClient, TTypedHttpClientImpl>()
    .ConfigureHttpClient(svc,httpClient =>
    {
        // how to resolve service on next line?
        var config = svc.GetRequiredService<IConfig>();
        httpClient.BaseAddress = config.GetBaseUrl();
    });

Оригинал

Вы можете использовать перегрузку AddHttpClient (IServiceCollection, String, Action <IServiceProvider, HttpClient>), чтобы передать IServiceProvider действию, которое можно использовать для разрешения других служб:

services
    .AddHttpClient<TTypedHttpClient, TTypedHttpClientImpl>((svc,httpClient =>
    {
        // how to resolve service on next line?
        var config = svc.GetRequiredService<IConfig>();
        httpClient.BaseAddress = config.GetBaseUrl();
    });

Я бы посоветовал прочитать серию статей Стива Гордона о типизированных HttpClients и HttpClientFactory. Использование типизированных клиентов из одноэлементных служб показывает, как использовать AddHttpClient для настройки клиента. В остальных его статьях показано, как настроить его с помощью HttpClientFactory и Polly для правильного объединения и повторных попыток.

Конфигурация

В примере Стива Гордона IOption используется для чтения данных из инфраструктуры конфигурации.

services.AddHttpClient<IConfigurationService, ConfigurationService>()
.ConfigureHttpClient((serviceProvider, client) =>
{
    var baseAddress = serviceProvider.GetRequiredService<IOptions<SdkOptions>>().Value.BaseAddress;
    client.BaseAddress = new Uri(baseAddress);
});

Это идея хороший - регистрация HttpClient не должна знать и не должна зависеть от источника его значений конфигурации. IConfig должен быть не чем иным, как конфигурационным DTO, загруженным на этапе настройки.

Конфигурация .NET Core может загружать значения из файлов json / xml / ini, баз данных, внешних служб, переменных среды, всего, что может возвращать значения в форме "section:subsection" - value. Он также позволяет комбинировать и перегружать настройки, что может быть полезно очень.

У меня есть приложения, которые загружают настройки из файлов (базовая конфигурация), баз данных, управляемых другими командами (конечные точки внешних служб и учетные данные), и из командной строки (возможные переопределения). Конфигурации конечной точки используются для создания N именованных HttpClients, по одному на конечную точку. Я использовал этот пример для создания поставщика EF Core, который загружает настройки конечной точки.

Это позволяет проверять настройки при запуске приложения, что может быть значительным преимуществом. Без него приложение не узнает, что что-то не так, пока не будет впервые запрошен конкретный HttpClient.