Provide the AddKeyedDbContext extension method on Services

[bit365]

Keyed services new features

Starting with .NET 8, there is support for service registrations and lookups based on a key, meaning it's possible to register multiple services with a different key, and use this key for the lookup.

See: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#keyed-services

services.AddKeyedSingleton<IMessageWriter, MemoryMessageWriter>("memory");
services.AddKeyedSingleton<IMessageWriter, QueueMessageWriter>("queue");

public class ExampleService
{
    public ExampleService([FromKeyedServices("queue")] IMessageWriter writer)
    {
        // Omitted for brevity...
    }
}

DbContext type needs to be enhanced

Provides the AddKeyedDbContext extension method on DbContext for injecting different configurations of the same type of DbContext. In some scenarios, such a design is required. For example, the following scenario.

Scene 1 database master-slave separation

The master database is used to write data, the slave database is used to read data.

services.AddKeyedDbContext<MyDbContext>("master",  options =>
{ 
    options.UseSqlServer(Configuration.GetConnectionString("Master"));
});

services.AddKeyedDbContext<MyDbContext>("slave",  options =>
{ 
    options.UseSqlServer(Configuration.GetConnectionString("Slave"));
});

Scene 2 database partition

For business situations with increasing data volume, consider sharding storage, where the database structure is the same but stored in different instances.

services.AddKeyedDbContext<MyDbContext>("db1",  options =>
{ 
    options.UseSqlServer(Configuration.GetConnectionString("Db1"));
});

services.AddKeyedDbContext<MyDbContext>("db2",  options =>
{ 
    options.UseSqlServer(Configuration.GetConnectionString("Db2"));
});

About compatibility

Providing the AddKeyedDbContext extension method for DbContext does not affect the original system and is only a type enhancement without disruptive changes.

Thank you, thank you very much.

[moklgydocs]

That's very elegant.

[dreamlab98]

It's a great extension and exactly what I needed

[amyboose]

Also DbContext support method GetService, but there is no method to get keyed service. It will be also good to have this one

[roji]

@amyboose DbContext.GetService() is for getting EF's internal services from inside EF's internal service provider, which is different from the application service provider. You generally should not need to call DbContext.GetService(), and in any case EF doesn't use keyed services for its internal services.

[ajcvickers]

@roji If the service is not registered in the internal service provider, then we try looking it up in the app service provider. So there could be a use for this, although I think the priority is quite low.

[roji]

@ajcvickers oh, I wasn't aware we had a systematic fallback to the app service provider when we fail to find something in the internal one. But would a keyed DbContext.GetService() be useful, given that we (EF) never register services with keys on the internal service provider? It would effectively just always fall through to the application service provider, so users might as well just resolve the service on the latter directly?

The OP though makes sense to me (i.e. adding AddKeyedDbContext() alongside the existing AddDbContext() on the application service provider).

[ajcvickers]

@roji I have seen DbContext used quite a lot to resolve application services inside data access code, like a repository. It's not necessarily the best practice, but it is certainly done.

The OP though makes sense to me (i.e. adding AddKeyedDbContext() alongside the existing AddDbContext() on the application service provider).

Agreed. Removing from the backlog to consider splitting into two issues.

It's interesting that we really wanted keyed services back in 2014 (the EF6 service resolver had it), but they were not available in the container abstraction then, which is why we use types to differentiate in places where a name would be better.