Redesign EF components public API

[eerhardt]

We've gotten feedback about missing EF scenarios - it started with Npgsql component doesn't allow configuration of the NpgsqlDbContextOptionsBuilder. We we fixed this by allowing to configure the DbContextOptionsBuilder, but this had the problem that the user needed to call UseNpgsql again to configure Npgsql specific options. Npgsql and SqlServer work this way, but CosmosDB doesn't - the UseCosmos API forces callers to pass a connection string, or other connection information.

Then more feedback came in that we don't support all the options that EF allows w.r.t. DependencyInjection:

• Add ability to configure NpgsqlDataSource #1276
• Please include AddSqlServerDbContextFactory #1241
• Add ability to modify the ServiceLifetime on AddSqlServerDbContext #1194
• [WebToolsE2E][Aspire]After adding 'Aspire.Npgsql.EntityFrameworkCore.PostgreSQL' component and updating related codes, F5 failed with an exception: 'Some services are not able to be constructed ...' #744 (the error happens because the scaffolding injects EF code into Program.cs)

Given all this feedback, and diving into the EF APIs, we think we need to redesign the Aspire EF component's public APIs. Today we are wrapping the EF APIs for Pooling or regular DbContext.

But instead, we should have the dev user call directly into the EF DependencyInjection APIs, so they have full control over what they want to add to the app. Then the Aspire EF Component can just have an extension method to add the other things:

• Health Checks
• Tracing
• Metrics
• Tracing
• Logging
• etc

The hard part will be coming up with the naming of that Aspire extension method. It can't be called AddNpgsqlDbContext anymore, since it doesn't add the DbContext.

[eerhardt]

Some other options I thought of. Not that I like any of them, but listing them here for completeness:

Add Settings properties to control behavior

Following the current design, which has

aspire/src/Components/Aspire.Npgsql.EntityFrameworkCore.PostgreSQL/NpgsqlEntityFrameworkCorePostgreSQLSettings.cs

Line 23 in cce3914

public bool DbContextPooling { get; set; } = true;

that controls how we add the DbContext to the ServiceCollection

aspire/src/Components/Aspire.Npgsql.EntityFrameworkCore.PostgreSQL/AspireEFPostgreSqlExtensions.cs

Lines 80 to 87 in cce3914

	if (settings.DbContextPooling)
	{
	builder.Services.AddDbContextPool<TContext>(ConfigureDbContext);
	}
	else
	{
	builder.Services.AddDbContext<TContext>(ConfigureDbContext);
	}

We could change this into an enum with Context, Pool, Factory options. This would solve #1241. And then for #1194 we add a ServiceLifetime property like in #1218.

The downfall of this approach is that if/when EF adds more options to adding DbContexts to the ServiceCollection we would need to add more options in Aspire. This is basically wrapping the EF API, which we don't want to do. It also doesn't solve #1276.

Take a optional Action callback

When an EF Aspire component wants to add to the ServiceCollection, it checks if this callback is set. If it is, it delegates to the user callback do to add the DbContext in whatever way it wants to the collection. For example:

builder.AddNpgsqlDbContext<MyContext>("connectionName", addDbContext: services =>
{
    services.AddDbContextFactory<MyContext>(... /* whatever the user wants to configure it */);
});

Have both simple and complex methods

In this option, we would still have the simple AddNpgsqlDbContext<MyContext>("connection") method, but also add the new complex method above for the cases when a dev wants to customize their DbContext adding to the ServiceCollection. So simple devs can just use our current APIs, and the more complex cases can use the full ability of EF overloads, and then call into the builder.AddAspireNpgsqlDbContextServices<MyContext>() proposed in the top comment.

cc @DamianEdwards @davidfowl @roji @ajcvickers @sebastienros - any thoughts on this issue?

[DamianEdwards]

I'm leaning towards requiring two methods to be called in all cases as it's the most consistent experience no matter how much of the EF Core call you need to customize.

[sebastienros]

Draft PR created with Npgsql changes #1706

AddNpgsqlDbContext doesn't add the DbContext anymore so it needs to be renamed. I used AddNpgsqlEntityFrameworkCore for now. It only registers and configures health-checks/tracing/metrics.