Add keyed options to dependency injection

[Dovencio]

With the current implementation of DI there is no easy way of configuring a keyed service. I see two ways of implementing keyed options:
Add ConfigureKeyed<TOption>(object? Key, // ...):

public class Service
{
    private readonly IOptions<ServiceOptions> options;
    // ...
    public Service(IOptions<ServiceOptions> options, // ...)
    {
        this.options = options;
        // ...
    }
}

public class ServiceOptions
{
    public string Property { get; set; }
    // ...
}

provider.Services.AddKeyedScoped<Service>("ServiceKeyA");
provider.Services.AddKeyedScoped<Service>("ServiceKeyB");
provider.Services.ConfigureKeyed<Service>("ServiceKeyA", o => {
    o.Property = "foo";
});
// ...

Or by passing the key into the constructor and use named configurations:

public class Service
{
    private readonly ServiceOption options;
    // ...
    public Service([ServiceKey] object? key, IOptionSnapshot<ServiceOptions> accessor)
    {
        string? serviceKey = key as string;
        if (serviceKey is null) throw Exception($"Service key {key} is null or not a string!");
        options = accessor.Get(serviceKey);
    }
}

public class ServiceOptions
{
    public string Property { get; set; }
    // ...
}

provider.Services.AddKeyedScoped<Service>("ServiceKeyA");
provider.Services.AddKeyedScoped<Service>("ServiceKeyB");
provider.Services.Configure<Service>("ServiceKeyA", o => {
    o.Property = "foo";
});
// ...

Personally I would prefer ConfigureKeyed function as it could provide multiple ways to configure as well as adding named configurations like ConfigureKeyed<Service>("ServiceA", "MyName", o => { // ... }); rather than use Configure<Service>("ServiceA.MyName", o => { // ... });.

Additionally using both ConfigureKeyed and Configure could make default options.

partial class Service
{
    string GetProperty() => options.Property;
}
// ...
provider.Services.AddScoped<Service>();
provider.Services.AddKeyedScoped<Service>("ServiceKeyA");
provider.Services.AddKeyedScoped<Service>("ServiceKeyB");
provider.Services.Configure<Service>(o => {
    o.Property = "Hello from default Service Config!";
});
provider.Services.ConfigureKeyed<Service>("ServiceKeyA", o => {
    o.Property = "Hello from ServiceKeyA Config!";
});
// ...

Service serveA = app.Services.GetKeyedService<Service>("ServiceKeyA");
Service serveB = app.Services.GetKeyedService<Service>("ServiceKeyB");
Service serveC = app.Services.GetService<Service>();

Console.WriteLine(serveA.GetProperty()); // "Hello from ServiceKeyA Config!"
Console.WriteLine(serveB.GetProperty()); // "Hello from default Service Config!"
Console.WriteLine(serveC.GetProperty()); // "Hello from default Service Config!"

[tacosontitan]

What prevents you from using abstractions as keys instead?

public interface ISampleService;
public interface IAlphaSampleService : ISampleService;
public interface IBravoSampleService : ISampleService;

...
services.AddScoped<IAlphaSampleService, AlphaSampleService>()
    .AddScoped<IBravoSampleService, BravoSampleService>()
    .AddScoped<ISampleService, DefaultSampleService>();
    
...
public sealed class Foo(IAlphaSampleService sampleService);

IMHO I prefer to have compile time enforcement of my services. If you're truly set on using runtime keys instead, then you could always create a factory for resolving things and an extension method on IServiceProvider that exposes it for consumption:

public interface IKeyedServiceFactory
{
    // just an example
    TService GetService<TService>(object key);
}

...
public static TService GetKeyedService<TService>(this IServiceProvider source, object key)
{
    var factory = source.GetRequiredService<IKeyedServiceFactory>();
    return factory.GetService<TService>(key);
}

...
var service = serviceProvider.GetKeyedService<SampleService>("alpha");

Though, again, I don't recommend this and will leave further exploration to the reader.

[Dovencio]

I'm having a frustration with IEmailSender's unable to pass in send from SendAsync. For example:
appsettings.json:

{
    "EmailClients": {
        "no-reply": {
            "email": "no-reply@example.com",
            "name": "no-reply"
        },
        "support": {
            "email": "support@example.com",
            "name": "support"
        }
    }
}

Program.cs:

// ...
foreach (IConfigurationSection child in builder.Configuration.GetSection("EmailClients").GetChildren())
{
    if (child.Key == "default")
    {
        builder.Services.AddScoped<IEmailSender, EmailSender>();
        builder.Services.Configure<EmailOtions>(defaultConfig);
    }
    else
    {
        builder.Services.AddKeyedScoped<IEmailSender, EmailSender>(child.Key);
        builder.Services.ConfigureKeyed<EmailOptions>(child.Key, child);
    }
}
// ...

controller.cs:

public class EmailSenderController(IServiceProvider provider) : PageController
{
    public async Task SendOnPost(string from, string to, string message)
    {
        IEmailSender sender = provider.GetKeyedService<IEmailSender>(from);
        sender ?= provider.GetRequiredService<IEmailSender>();
        await sender.SendEmailAsync(to, "Your car's extended warranty", message);
   }
}

This way if I want to add abuse@example.com I don't have to recompile and publish the whole thing, I just need to add the new entry into appsettings.json.

[tacosontitan]

This screams X/Y problem to me. Personally, I'd recommend using something like:

public interface IEmail;
public sealed class SupportEmail(IOptionsMonitor<Sample> options)
{
    ... get support email details from appsettings here
}

...
var emailProvider = provider.GetRequiredSerivce<IEmailProvider>();
var email = new SupportEmail(to, subject, message);
await emailProvider.Send(email, cancellationToken);

[Dovencio]

This is where you've lost me because I've already solved that specific issue and my solution doesn't look like yours. I'm not here to look for a solution, I'm here to offer an idea that I believe would help streamline what I did to solve the issue. There can't be an XY problem if Y has already been solved. I should rephrase to be clear, if the functions AddKeyed{Scope}<T>(object? key) exists, why doesn't/shouldn't the function ConfigureKeyed<T>(object? key, ...) exist?

[tacosontitan]

Ah, I now see that this is an issue of me missing a critical component of your question, configuration as opposed to registration. My apologies!

[SerratedSharp]

I really miss keyed services. If you have an interface with multiple concrete implementations, and you want DB or config file driven selection of the implementation, they are really great. I can implement handlers for a dozen different payment vendors, and in a multi tenant system allow my clients to configure their payment vendor, and have the appropriate implementation light up. Done properly all the other code on each side of the pipeline leverages the interface, and the configuration drives the selection of the concrete implementation. They are really great when used properly. When you show another dev how easy it is with a bit of declarative config to switch implementations, and eliminate repetitive blocks of switch cases and redundant concrete classes, they begin to really appreciate this approach.

Usually counter examples that don't understand how to implement this properly will hard code a string during the service resolution. That's the wrong way to leverage this approach. You would pass a string, but it wouldn't be hardcoded, it would be determined at runtime based on some dynamic or data driven process.

HttpClient was another great use of them. You generally want a single HttpClient instead per integration. But you don't want one HttpClient for the entire app, because there's alot of things like timeout property that cannot be changed on HttpClient after the first request. If you have multiple integrations, then you want one HttpClient per integration, so the BaseUri, Timeout, etc. can be specific to the remote integration. Keyed service registration solved this problem cleanly. Creating a bunch of class declarations for what differs only by some configuration is unnecessary bloat, and results in the consuming code being overly coupled to what would have otherwise just been an HttpClient. They all share the same interface, there's no need for different types. For this use case, having attributes on constructor parameters that name the desired implementation made more sense, because you usually wanted the specifically configured HttpClient singleton for a particular section of code. The big difference here is there aren't multiple implementations, but instead there's a single implementation with multiple singleton instances. I.e. if I have a integration with Google API and one with OpenAI, then I need a singleton HttpClient for Google API, and another singleton HttpClient for OpenAI.

I thought it was real interesting when we got the extension methods for .AddHttpClient that take a name, which is basically exposing them as keyed service outside of DI. I felt vindicated. It would have made more sense to just fix the DI though IMO.