-
Notifications
You must be signed in to change notification settings - Fork 261
Description
minio-dotnet/Minio/ServiceCollectionExtensions.cs
Lines 36 to 63 in 2e976c1
| public static IServiceCollection AddMinio( | |
| this IServiceCollection services, | |
| Action<IMinioClient> configureClient, | |
| ServiceLifetime lifetime = ServiceLifetime.Singleton) | |
| { | |
| if (services is null) throw new ArgumentNullException(nameof(services)); | |
| if (configureClient == null) throw new ArgumentNullException(nameof(configureClient)); | |
| var minioClientFactory = new MinioClientFactory(configureClient); | |
| services.TryAddSingleton<IMinioClientFactory>(minioClientFactory); | |
| var client = minioClientFactory.CreateClient(); | |
| client.Config.ServiceProvider = services.BuildServiceProvider(); | |
| switch (lifetime) | |
| { | |
| case ServiceLifetime.Singleton: | |
| services.TryAddSingleton(_ => client); | |
| break; | |
| case ServiceLifetime.Scoped: | |
| services.TryAddScoped(_ => client); | |
| break; | |
| case ServiceLifetime.Transient: | |
| services.TryAddTransient(_ => client); | |
| break; | |
| } | |
| return services; | |
| } |
-
Why is a separate ServiceProvider created by calling BuildServiceProvider directly, rather than using the ServiceProvider supplied by the Application/Host?
-
Why is createClient called ahead of time to create the minioClient, rather than creating the instance inside the factory method passed to the ServiceCollection? With the current approach, regardless of what ServiceLifetime is specified, the same instance will be injected, right?
In my view, it may just be that the default lifecycle is singleton by chance and almost no one provides other parameters, which has caused the chaotic logic in this method to be concealed. Fix it, my brothers.