---
title: "Best practices for connection string management in Dapper-based ASP.NET Core APIs"  
description: "Best practices for connection string management in Dapper-based ASP.NET Core APIs"  
author: "John Smith"  
published: 2026-09-30  
updated: 2026-09-30  
canonical: https://www.mindstick.com/forum/162221/best-practices-for-connection-string-management-in-dapper-based-asp-net-core-apis  
category: "Configuration"  
tags: ["Dapper", "Configuration", "security", "asp.net core", "Connection Pooling"]  
reading_time: 1 minute  

---

# Best practices for connection string management in Dapper-based ASP.NET Core APIs

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:

```cs
// 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`?


---

Original Source: https://www.mindstick.com/forum/162221/best-practices-for-connection-string-management-in-dapper-based-asp-net-core-apis

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.