Создать несколько экземпляров одной и той же зависимости с разной конфигурацией
У меня есть приложение (IJobInit), которое использует список из настроек JSON для создания нескольких экземпляров класса (IJob). Этот класс выполняет некоторую работу, используя две другие зависимости, IInputClient и IOutputClient. Он использует M.Extensions.DependencyInjection для создания контейнера, который передается AutoFac для создания IContainer.
IJobInit(IContainer container)
Я бы хотел, чтобы IInputClient настраивался по-разному для каждого экземпляра IJob. Говоря формально, я хотел бы передать секрет для его использования. Результатом будет:
IInputClient(HttpClient client)
где HttpClient настроен с использованием НастроитьHttpClient, так что IJob не знает, что он предварительно аутентифицирован. Это также подойдет:
IInputClient(ISecretProvider secretsProvider, string secretName)
Конечным результатом являются три экземпляра IJob с по-разному настроенным IInputClient.
IJob(IInputClient inputClient1, IOutputClient outputClient)
IJob(IInputClient inputClient2, IOutputClient outputClient)
IJob(IInputClient inputClient3, IOutputClient outputClient)
Как мне этого добиться? Я смотрел на области Autofac, но эти элементы управления при создании экземпляра без какого-либо контроля над его конфигурацией (если я не пропустил это).
Коллега предложил мне разместить каждый экземпляр IJob в отдельном процессе с его собственной конфигурацией, что возможно является, но я пытаюсь разместить все задания в одной функции Azure и использовать список в конфигурации для создания внутренних заданий.
Спасибо!
Также похоже, что у вас несколько контейнеров ... эти типы конфигураций действительно редки, я не понимаю, зачем это нужно для вашей реализации. При второй проверке вам может потребоваться создать еще один уровень абстракции для вашего IInputClient, заменив HttpClient объектом, который знает о секретной реализации, хотя вы могли бы использовать предварительная настройка именованных экземпляров, но я не уверен, что вы получите то, что вам нужно.
Мне очень нравятся перечисленные отношения. Думаю, я мог бы использовать провайдеров Autofac и для их программной регистрации.
Ответы 1
Я не совсем доволен этим решением, но пока оно работает.
private async Task<IInputClient> GetClientAsync(string secretId)
{
HttpClient httpClient = this.httpClientFactory.CreateClient();
string secret = await this.secretsProvider.GetSecretAsync(secretId);
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(Encoding.ASCII.GetBytes(string.Concat(":", secret))));
return this.scope.Resolve<IInputClient>(new TypedParameter(typeof(HttpClient), httpClient));
}
Почему бы вам не использовать IInputClient в качестве зависимости для любого класса, к которому относится этот метод?
Я делаю. Я использую клиент, созданный этим методом, для создания списка IProcessor(IInputClient, IOutputClient), а затем просматриваю их. IInputClient client = await this.GetClientAsync(this.GetKeyVaultSecretUri(kvp.Key)); var proc = this.scope.Resolve<Processor>(new NamedParameter("inputClient", client));
вы продолжаете использовать Resolve. Используя внедрение зависимостей, вам редко когда когда-либо понадобится разрешать что-либо вручную ...
Я не согласен. Документы описывают IRegistrationSource, который почти делает то, что мне нужно, но возвращает A, B, C, где я хочу A, A ', A' ', A' '' и так далее.
Я думаю, что если бы я мог динамически регистрировать экземпляры в контейнере до (или после) его сборки, я мог бы использовать функцию перечислителя для упрощения. Обновлено: Может быть, RegistrationSource может это сделать, хотя мне все равно нужно вызвать разрешение в активаторе. Мне нужно провести еще несколько исследований и поэкспериментировать. (все еще относительно новичок во всем этом!)
Похоже, вы перевернули свой контроль, что является причиной проблемы. Если у вас была перечислимая конфигурация, создайте перечислимый
IJobInit/IJobна основе количества конфигураций. Autofac поддерживает Неявно пронумерованные отношения.