Si proporciona una conexión SQL como singleton, no podrá atender varias solicitudes al mismo tiempo a menos que habilite MARS, que también tiene sus limitaciones. La mejor práctica es usar una conexión SQL transitoria y asegurarse de que se elimine correctamente.

En mis aplicaciones, paso una IDbConnectionFactory personalizada a los repositorios que se usa para crear una conexión dentro de la instrucción using . En este caso, el repositorio en sí mismo puede ser único para reducir las asignaciones en el montón.

Gran pregunta, y ya dos grandes respuestas. Esto me desconcertó al principio y se me ocurrió la siguiente solución para resolver el problema, que encapsula los repositorios en un administrador. El propio administrador se encarga de extraer la cadena de conexión e inyectarla en los repositorios.

Encontré este enfoque para probar los repositorios individualmente, digamos en una aplicación de consola simulada, mucho más simple, y tuve mucha suerte siguiendo este patrón en varios proyectos a mayor escala. ¡Aunque es cierto que no soy un experto en pruebas, inyección de dependencia o, bueno, nada en realidad!

La pregunta principal que me pregunto es si DbService debería ser un singleton o no. Mi razón era que no tenía mucho sentido crear y destruir constantemente los diversos repositorios encapsulados en DbService y dado que todos son apátridas, no vi muchos problemas en permitirles "vivir". Aunque esto podría ser una lógica completamente inválida.

EDITAR: si desea una solución lista para usar, consulte la implementación de mi repositorio Dapper en GitHub

El gestor de repositorios está estructurado de la siguiente manera:

 /* * Db Service */ public interface IDbService { ISomeRepo SomeRepo { get; } } public class DbService : IDbService { readonly string connStr; ISomeRepo someRepo; public DbService(string connStr) { this.connStr = connStr; } public ISomeRepo SomeRepo { get { if (someRepo == null) { someRepo = new SomeRepo(this.connStr); } return someRepo; } } }

Un repositorio de muestra estaría estructurado de la siguiente manera:

 /* * Mock Repo */ public interface ISomeRepo { IEnumerable<SomeModel> List(); } public class SomeRepo : ISomeRepo { readonly string connStr; public SomeRepo(string connStr) { this.connStr = connStr; } public IEnumerable<SomeModel> List() { //work to return list of SomeModel } }

Conectando todo:

 /* * Startup.cs */ public IConfigurationRoot Configuration { get; } public void ConfigureServices(IServiceCollection services) { //...rest of services services.AddSingleton<IDbService, DbService>(); //...rest of services }

Y finalmente, usándolo:

 public SomeController : Controller { IDbService dbService; public SomeController(IDbService dbService) { this.dbService = dbService; } public IActionResult Index() { return View(dbService.SomeRepo.List()); } }

Estoy de acuerdo con @Andrii Litvinov, tanto la respuesta como el comentario.

En este caso, optaría por el enfoque de la fábrica de conexiones específica de la fuente de datos.

Con el mismo enfoque, estoy mencionando una forma diferente: UnitOfWork.

Consulte DalSession y UnitOfWork de esta respuesta. Esto maneja la conexión.
Consulte BaseDal de esta respuesta. Esta es mi implementación de Repository (en realidad BaseRepository ).

• UnitOfWork se inyecta como transitorio.
• Se pueden manejar múltiples fuentes de datos creando DalSession separadas para cada fuente de datos.
• UnitOfWork se inyecta en BaseDal .

¿Existen recomendaciones/mejores prácticas con respecto a la vida útil del objeto SqlConnection cuando se trabaja con Dapper?

Una cosa en la que la mayoría de los desarrolladores está de acuerdo es que la conexión debe ser lo más breve posible. Veo dos enfoques aquí:

1. Conexión por acción.
   Esto, por supuesto, será la vida útil más corta de la conexión. Encierras la conexión using un bloque para cada acción. Este es un buen enfoque siempre que no desee agrupar las acciones. Incluso cuando desee agrupar las acciones, puede usar transacciones en la mayoría de los casos.
   El problema es cuando desea agrupar acciones en varias clases/métodos. No puede using el bloque de uso aquí. La solución es UnitOfWork como se muestra a continuación.
2. Conexión por Unidad de Trabajo.
   Defina su unidad de trabajo. Esto será diferente por aplicación. En la aplicación web, la "conexión por solicitud" es un enfoque ampliamente utilizado.
   Esto tiene más sentido porque generalmente hay (la mayoría de las veces) un grupo de acciones que queremos realizar como un todo. Esto se explica en dos enlaces que proporcioné anteriormente.
   Otra ventaja de este enfoque es que la aplicación (que usa DAL) obtiene más control sobre cómo se debe usar la conexión. Y, según tengo entendido, la aplicación sabe mejor que DAL cómo se debe usar la conexión.