Tutorial de Conexión SQL de C#: Dapper + Explicación de la Base de Datos SQL Server

Tim Corey

1h 15m 23s

En la Lección 10 de la serie "C# App Start to Finish" de Tim Corey, Tim explica cómo conectar una aplicación C# a una base de datos SQL Server usando Dapper. En la lección anterior, la aplicación usó una capa de acceso a datos falsa que solo pretendía hablar con SQL. En este video, Tim reemplaza ese código de marcador de posición con lógica real de conexión SQL y muestra cómo configura una verdadera conexión a bases de datos de una manera limpia, escalable y fácil de mantener.

Este artículo desglosa los conceptos clave que Tim cubre y los explica de una manera que tiene sentido incluso si eres nuevo en la conexión SQL de C# o SQL Server.

Configuración y limpieza del proyecto

Tim comienza revisando la estructura de la solución y confirmando los cambios realizados en la lección anterior. En Program.cs, explica que agregó código para conectarse tanto a SQL Server como a bases de datos de archivos de texto, y cambió el formulario de inicio al formulario "Crear premio" para poder probar la conexión a la base de datos de inmediato.

Luego limpia la estructura del proyecto creando dos carpetas:

• Modelos

• DataAccess

Señala que esto no afecta la funcionalidad del código fuente, pero ayuda con la organización. Cuando vuelves a un proyecto más tarde, una estructura limpia y una nomenclatura consistente hacen que sea mucho más fácil de mantener y expandir.

¿Por qué Dapper?

Tim explica que usará Dapper como el ORM (Mapeador Objeto-Relacional) para las conexiones SQL. Dapper se sitúa entre los comandos SQL en bruto y los ORM de nivel superior como Entity Framework.

Tim prefiere Dapper porque es:

• Casi tan rápido como ADO.NET en bruto

• Más simple que Entity Framework

• Evita la complejidad innecesaria y el código pesado de plantilla

Menciona que Entity Framework puede ser más lento y pesado, especialmente para aplicaciones pequeñas. Para su proyecto, Dapper proporciona el equilibrio adecuado entre rendimiento y simplicidad.

Instalando Dapper

Tim demuestra cómo instalar Dapper a través de NuGet Package Manager en Visual Studio. Después de la instalación, Dapper aparece en las referencias del proyecto, y el código de conexión SQL se vuelve limpio y legible.

Agregando la cadena de conexión

Para usar Dapper, necesitas una cadena de conexión. Tim la agrega al archivo app.config del proyecto de UI, no al proyecto de biblioteca, porque la biblioteca es un DLL y no tiene su propia configuración.

La cadena de conexión incluye:

• Fuente de datos (nombre del servidor o nombre del dominio de la máquina)

• Catálogo inicial (nombre de la base de datos)

• Seguridad integrada (Autenticación de Windows)

• Tiempo de espera de la conexión

• ID de usuario y contraseña (si no se usa la autenticación de Windows)

En el ejemplo de Tim, utiliza conexión de confianza, es decir, autenticación de Windows:

Data Source=SQL2016;Initial Catalog=Tournaments;Integrated Security=True;

Data Source=SQL2016;Initial Catalog=Tournaments;Integrated Security=True;

Él enfatiza que esto evita almacenar las credenciales de usuario de SQL Server en el archivo.

GlobalConfig: Obtener la cadena de conexión

Para recuperar la cadena de conexión, Tim agrega un método en GlobalConfig:

public static string GetConnectionString(string name)
{
    return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

public static string GetConnectionString(string name)
{
    return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

Este método extrae la cadena de conexión del archivo de configuración y la devuelve. Tim también agrega la referencia requerida de System.Configuration.

Creando la conexión SQL

Tim elimina el código de reserva y crea un SqlConnection real usando:

using (IDbConnection connection = new SqlConnection(
    GlobalConfig.GetConnectionString("tournaments")))
{
    // Lógica de SQL aquí
}

using (IDbConnection connection = new SqlConnection(
    GlobalConfig.GetConnectionString("tournaments")))
{
    // Lógica de SQL aquí
}

Usa una interfaz IDbConnection para que pueda cambiar los tipos de base de datos (SQL o archivo de texto) sin cambiar el código principal.

El bloque using es importante porque asegura que la conexión se cierre automáticamente cuando el código sale del bloque. Esto evita conexiones abiertas que pueden agotar el pool de conexiones o causar errores en el servidor de base de datos.

Creando el procedimiento almacenado

En lugar de escribir SQL en bruto dentro de C#, Tim usa un procedimiento almacenado. Esto mantiene la lógica SQL en la base de datos y reduce riesgos como la inyección SQL.

Crea un procedimiento almacenado llamado:

dbo.SP_Prizes_Insert

dbo.SP_Prizes_Insert

Este procedimiento toma parámetros que coinciden con la tabla de premios:

• @PlaceNumber

• @PlaceName

• @PrizeAmount

• @PrizePercentage

• @ID (salida)

El parámetro de salida devuelve el ID que se genera nuevo usando:

SELECT @ID = SCOPE_IDENTITY()

SELECT @ID = SCOPE_IDENTITY()

Esto asegura que el ID del nuevo registro se devuelva a la aplicación C#.

Parámetros dinámicos en Dapper

De vuelta en C#, Tim usa DynamicParameters de Dapper para enviar parámetros al procedimiento almacenado:

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

El ID se marca como Output, y Dapper maneja el mapeo de parámetros.

Ejecutando el procedimiento almacenado

Él ejecuta el procedimiento almacenado:

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

Execute se usa porque realiza una inserción y no devuelve filas como una instrucción SELECT.

Después de la ejecución, el código recupera el ID:

model.ID = p.Get<int>("@ID");
return model;

model.ID = p.Get<int>("@ID");
return model;

Pruebas y Resultados

Tim ejecuta la aplicación, llena el formulario y hace clic en Crear Premio. Los datos se insertan en la base de datos SQL Server con éxito. Prueba ambas:

• Cantidad del Premio

• Porcentaje del Premio

Ambas funcionan, demostrando que la conexión a la base de datos y el procedimiento almacenado funcionan correctamente.

Desafío de diseño: múltiples conectores de datos (1:01:50)

Tim destaca un problema de diseño: usar ambos conectores SQL y de archivo de texto simultáneamente causa IDs inconsistentes.

Así que cambia el diseño para que solo un conector se ejecute a la vez. Él agrega un enum:

TipoDeBaseDeDatos
{
SQL,
    ArchivoDeTexto
}

TipoDeBaseDeDatos
{
SQL,
    ArchivoDeTexto
}

Esto asegura que la aplicación siempre use un tipo de base de datos consistente y previene mezclar datos de diferentes fuentes de base de datos.

Conclusión

La Lección 10 de Tim Corey muestra un enfoque del mundo real para conectar una aplicación C# a SQL Server usando Dapper. Él cubre:

• Agregando una cadena de conexión

• Usando SqlConnection

• Abriendo y cerrando conexiones de manera segura

• Usando procedimientos almacenados

• Evitando la inyección SQL

• Arquitectura adecuada para múltiples fuentes de datos

Si deseas una forma limpia, rápida y mantenible para conectar C# a una base de datos SQL Server, esta lección es una guía perfecta.