y0ung3r
commented
1 year ago Если коротко, то ваше решение ужасно.
Вы не понимаете смысл контейнера зависимостей. Его суть в том, что он забирает на себя разрешение всех зависимостей в приложении. А в приведенном вами коде вы пытаетесь зарезолвить что то сами, да еще и в каждом скоупе создаете дополнительные IServiceCollection. В общем, жуть полная :)
Я не пытаюсь принизить, отнюдь. Просто покажу как должно быть правильно.
Фактически IServiceCollection - это просто список. Список всех зависимостей. Причем вообще не важно в каком порядке все зарегистрировано.
Воспринимайте каждый тип параметра конструктора вашего класса, который вы зарегистрируйте в контейнер, как тип, который тоже уже зарегистрирован в контейнере:
public class A
{
public A(B b, C c)
{
// ...
}
}Если мы хотим serviceProvider.GetRequiredService<A>(), то A, B, C должны быть зарегистрированы в контейнере зависимостей:
public static void AddA(
this IServiceCollection services)
{
services.AddScoped<A>();
services.AddScoped<B>();
services.AddScoped<C>();
}Иногда бывает такое, что A принимает дополнительный параметр, который ну никак нельзя зарегистрировать в контейнере зависимостей:
public class A
{
public A(B b, C c, string name)
{
// ...
}
}В таких случаях можно использовать фабрику:
public static void AddA(
this IServiceCollection services)
{
services.AddScoped<B>();
services.AddScoped<C>();
services.AddScoped<A>(provider =>
new A(provider.GetRequiredService<B>(), provider.GetRequiredService<C>(), "CONST NAME")); // Или через ActivatorUtilities
}Здесь стоит оговориться, что фабрики вообще очень мощный инструмент для передачи дополнительных параметров в контейнере зависимостей. Погуглите использование фабрик в IServiceCollection самостоятельно. Но я остановился на самом простом примере.
После того, как все зависимости будут зарегистрированы в контейнере зависимостей, собирается IServiceProvider через services.BuildServiceProvider(), который и будет предоставлять вам зависимости в экземпляр класса указанного типа.
Из всего вышесказанного делаем вывод, что IServiceCollection должен создаваться ровно 1 раз где то в точке входа вашего приложения, обычно это Program.cs (однако в ASP.NET автоматически уже предоставляется IServiceCollection для конфигурации)
В вашем случае код должен быть примерно такой (я не вникал [и не хочу] в суть ваших зависимостей):
public static void AddVkontakteClient<TProxyProvider, TCaptchaSolver>(
this IServiceCollection services,
Action<VkontakteApiOptions> configure)
where TProxyProvider : class, IProxyProvider
where TCaptchaSolver : class, ICaptchaSolver
{
services.Configure(configure);
services.AddScoped<IVkontakteApiClient, VkontakteApiClient>();
services.AddSingleton(typeof(IProxyProvider), typeof(TProxyProvider));
services.AddSingleton<ProxyHttpHandler>();
services
.AddHttpClient<IRestClient, RestClient>()
.ConfigurePrimaryHttpMessageHandler<ProxyHttpHandler>();
services.AddAudioBypass();
services.AddSingleton(typeof(ICaptchaSolver), typeof(TCaptchaSolver));
var vkApi = new VkApi(services);
services.AddSingleton(vkApi);
}Соответственно, когда вам понадобится VkApi, запрашиваем его через конструктор и получаем правильно сконфигурированный сервис:
public class A
{
public A(VkApi apiClient)
{
// apiClient уже имеет TCaptchaSolver, AudioBypass и все, что вы ему там нарегистрировали.
}
}
bretbas
Rast1234
CaCTuCaTu4ECKuu
Здравствуйте Пилю сейчас проект с использованием вашей библиотеки (спасибо за проект). У меня есть вопрос, касаемо DI, который я не могу понять как правильно решить. Вся проблема заключается в том, что VkApi принимает "почему-то" в параметрах IServiceCollection.
У меня есть вот такой вот код:
Он регистрирует VkontakteApiClient как scoped, при этом VkontakteApiClient принимает у меня VkApi тоже как scoped.
Я хочу узнать два момента:
public static void AddVkontakteClient<TProxyProvider, TCaptchaSolver>не очень хочется (так как он там не нужен)