We're moving a legacy service to use Dapper, and I'm unsure where to keep the SQL Server connection string. I know not to hardcode it, but I'm torn between appsettings.json, Azure Key Vault, and environment variables.

Local development

For my machine, I usually just drop it in appsettings.json under a ConnectionStrings section. It's quick, but I worry about accidentally committing it if I use a shared repo.

Production

In Azure App Service, I've seen teams inject it via Application Settings. That works, yet it feels less structured than a dedicated secrets manager. If we go with Key Vault, how much extra plumbing does Dapper actually require? Do I need a custom IDbConnectionFactory, or can I resolve SqlConnection directly from DI?

Quick example

Here's how I currently register it:

// Register SqlConnection in Program.cs
builder.Services.AddScoped<IDbConnection>(() => 
    new SqlConnection(builder.Configuration.GetConnectionString("Default")));

Is this safe enough, or should I be wrapping it in a factory pattern? Also, any gotchas with connection pooling when the lifetime is Scoped?