Curso de Dapper ORM para Empresas — Acceso a datos eficiente

Configuración de una solución base en .NET 10 con una estructura preparada para servicios, APIs, librerías de acceso a datos y tests.

Revisión de novedades de .NET 10 y C# 14 que impactan indirectamente en productividad, expresividad y organización del código.

Preparación de Visual Studio 2026 o VS Code, SDK, CLI, debugging y configuración de proyectos de backend.

Diseño de una estructura de carpetas y proyectos que separe contratos, consultas, infraestructura y casos de uso.

Integración de paquetes NuGet principales y auxiliares para logging, configuración, tests y métricas.

Revisión de cadenas de conexión, `appsettings`, secretos y configuración por entorno.

Preparación de un entorno SQL local o de laboratorio listo para pruebas repetibles.

Detección de problemas habituales de arranque antes de entrar en SQL y Dapper propiamente dichos.

Construcción de un repo limpio y reproducible para trabajar en equipo desde el primer día.

Taller de bootstrap completo del entorno .NET 10 + Dapper.

Revisión de `DbConnection`, `DbCommand`, `DbParameter`, `DbTransaction` y `DbDataReader` como base real sobre la que opera Dapper.

Comprensión de por qué Dapper extiende `DbConnection` y no pretende abstraer por completo el motor relacional.

Trabajo sobre apertura, cierre y disposición de conexiones en servicios HTTP, jobs y procesos largos.

Análisis del ciclo real de una consulta desde el código C# hasta el motor SQL.

Revisión de la importancia del pool de conexiones y de no tratar la conexión como recurso permanente.

Diferenciación entre ejecutar, leer, escalar y procesar múltiples resultados desde la óptica ADO.NET.

Preparación de una mentalidad de bajo nivel suficiente para entender bien los efectos de Dapper.

Detección de errores que en realidad son de ADO.NET, pero se atribuyen incorrectamente a Dapper.

Construcción de una base técnica firme para el resto del curso.

Ejercicios de lectura y escritura con ADO.NET comparados con Dapper para entender exactamente qué simplifica.

Diseño de estrategias de apertura y cierre de conexión seguras y eficientes en aplicaciones ASP.NET Core.

Revisión de factories, wrappers mínimos y patrones de obtención de conexiones por request, handler o job.

Trabajo sobre el equilibrio entre no duplicar boilerplate y no esconder en exceso la infraestructura relacional.

Preparación de conexiones para SQL Server, PostgreSQL y SQLite según contexto de laboratorio o proyecto.

Detección de problemas al compartir conexiones en lugares donde no deben compartirse.

Revisión de timeouts, cancelación y manejo de fallos de conexión en código real.

Construcción de helpers razonables para obtener conexiones sin enturbiar la capa de datos.

Trabajo sobre el coste de abrir demasiado pronto o demasiado tarde la conexión en operaciones complejas.

Preparación de un patrón consistente de uso para controllers, minimal APIs y servicios.

Taller de gestión correcta del ciclo de vida de la conexión en varios escenarios.

Dominio de los métodos base de Dapper para lectura de múltiples filas, una sola fila, ejecución sin resultado y escalares.

Revisión detallada de `Query<T>`, `QueryFirst<T>`, `QuerySingle<T>`, variantes `OrDefault` y criterios para elegir cada una.

Trabajo sobre cómo la semántica de cada método expresa expectativas de cardinalidad y errores del caso de uso.

Preparación de una capa de acceso que use el método correcto según la intención funcional y no por costumbre.

Detección de bugs silenciosos al usar `First` donde debería haberse usado `Single`, o viceversa.

Revisión de `Execute` para `INSERT`, `UPDATE` y `DELETE` con manejo adecuado del número de filas afectadas.

Construcción de consultas escalares para contadores, flags, ids y cálculos simples con `ExecuteScalar`.

Trabajo sobre nomenclatura y diseño de métodos de repositorio o consulta alineados con el método Dapper utilizado.

Preparación de ejemplos reales de lectura simple, escritura y consulta puntual con semántica clara.

Taller completo de CRUD básico con los métodos principales de Dapper.

Uso correcto de objetos anónimos y POCOs para enviar parámetros nombrados sin caer en concatenación insegura.

Revisión de `DynamicParameters` cuando se necesita construir queries de forma más dinámica o manejar múltiples fuentes.

Trabajo sobre mezcla de parámetros estáticos y dinámicos dentro de una misma consulta.

Preparación de parámetros opcionales, nulos, tipos explícitos y binding controlado por nombre.

Detección de errores habituales de naming, nullabilidad o tipos que dan lugar a bugs difíciles de rastrear.

Revisión del papel de `Dictionary<string, object>` y de cuándo realmente compensa frente a otras opciones.

Construcción de helpers para queries con muchos filtros sin sacrificar seguridad ni legibilidad.

Trabajo sobre la relación entre parámetros correctos y reutilización de planes en el motor SQL.

Preparación de convenciones de parámetros para equipos con varias bases o varios proveedores.

Taller de rediseño de queries mal parametrizadas hacia una versión limpia con Dapper.

Uso de listas e `IEnumerable<T>` para cláusulas `IN` sin construir SQL manualmente a base de strings.

Revisión de cómo Dapper expande internamente listas parametrizadas y qué implicaciones tiene eso en consultas reales.

Trabajo sobre `DbString` para controlar comportamiento ANSI, unicode, longitud y casos sensibles en SQL Server.

Preparación de procedimientos con parámetros de salida, parámetros de retorno y lectura posterior de valores.

Detección de escenarios donde conviene explicitar `DbType`, longitud o dirección del parámetro para evitar sorpresas.

Revisión de procedimientos almacenados que devuelven ids, flags o mensajes a través de `DynamicParameters`.

Construcción de patrones reutilizables para llamadas complejas a stored procedures.

Trabajo sobre la frontera entre consulta cómoda y pérdida de claridad cuando el set de parámetros se vuelve excesivo.

Preparación de una disciplina para documentar y validar contratos SQL con múltiples parámetros.

Taller de uso avanzado de `DynamicParameters`, listas y outputs en código productivo.

Diseño de tipos de salida claros para queries de lectura, sin depender obligatoriamente de entidades ricas o modelos de dominio completos.

Revisión del mapping automático por nombre de columna y propiedad, y del valor de usar aliases limpios en SQL.

Trabajo sobre tipos inmutables, records, DTOs y modelos internos para consultas específicas.

Preparación de resultados bien tipados para listados, detalle, reporting y vistas de API.

Detección de problemas cuando se fuerza una misma clase para demasiados casos de lectura diferentes.

Revisión de nullabilidad, tipos valor, enums y conversiones implícitas durante el mapping.

Construcción de clases de consulta expresivas y desacopladas del motor de persistencia.

Trabajo sobre cómo evitar diseños donde el SQL queda atado a nombres ambiguos o pobres de propiedades.

Preparación de estrategias de naming que hagan el mapping más fiable y más legible.

Taller de diseño de modelos de lectura y mapping limpio desde SQL.

Comprensión del soporte síncrono y asíncrono de Dapper y de cuándo conviene cada camino en .NET 10.

Revisión de consultas bufferizadas frente a no bufferizadas y del efecto que tienen sobre memoria, locks y throughput.

Trabajo sobre cómo `buffered: false` permite procesar grandes resultados con menor huella de memoria.

Preparación de flujos asíncronos correctos con cancelación, timeouts y manejo de excepciones.

Detección de errores típicos cuando se intenta enumerar fuera del alcance de la conexión en queries no bufferizadas.

Revisión del impacto de las lecturas enormes sobre red, CPU y tiempo de retención de recursos.

Construcción de criterios para elegir entre simplicidad de uso y streaming controlado.

Trabajo sobre cómo usar async de verdad en APIs y jobs sin degradar la consistencia del código.

Preparación de benchmarks simples entre buffering y streaming sobre datasets realistas.

Taller de lectura asíncrona y unbuffered sobre conjuntos de datos grandes.

Dominio de la capacidad de Dapper para mapear una misma fila sobre varios objetos y recomponer un resultado más rico.

Revisión del patrón `Query<TFirst, TSecond, TReturn>` y de la función de ensamblado entre objetos.

Trabajo sobre `splitOn` cuando la columna de corte no sigue la convención `Id` o `id`.

Preparación de joins uno a uno y uno a muchos ligeros con mapping manual bien controlado.

Detección de errores clásicos de duplicación de padres al hacer joins amplios y no colapsar correctamente la colección.

Revisión de cuándo el multi-mapping mejora la solución y cuándo conviene separar lecturas.

Construcción de consultas multi-mapping legibles y mantenibles, sin convertir el SQL en una pieza inentendible.

Trabajo sobre combinaciones de varios tipos y retorno final distinto de los tipos intermedios.

Preparación de estrategias para agregados simples y para lecturas compuestas por necesidad de pantalla o API.

Taller completo de joins con multi-mapping y uso correcto de `splitOn`.

Uso de `QueryMultiple` para recuperar varias rejillas de resultados relacionadas con un único viaje a base de datos.

Revisión de escenarios donde es útil: detalle con sublistas, dashboards, lookups múltiples y pantallas compuestas.

Trabajo sobre `GridReader` conceptual, orden de lectura y contratos claros entre SQL y consumo posterior.

Preparación de consultas por lotes que reducen roundtrips sin degradar demasiado legibilidad.

Detección de errores de orden o shape de resultados cuando cambia el SQL y no se ajusta el código consumidor.

Revisión de ventajas y límites de este enfoque frente a multi-mapping o queries separadas.

Construcción de servicios de lectura complejos con una sola llamada bien diseñada.

Trabajo sobre transacciones y consistencia cuando varias rejillas deben reflejar el mismo instante lógico.

Preparación de DTOs compuestos y ensamblaje posterior de la respuesta final.

Taller de construcción de una pantalla compleja con `QueryMultiple`.

Revisión del soporte directo de Dapper para stored procedures y de cómo invocarlos correctamente.

Trabajo sobre paso de parámetros de entrada, salida y retorno con contratos claros.

Preparación de procedimientos para lectura, escritura, acciones administrativas y flujos heredados.

Detección de cuándo un procedimiento aporta realmente valor y cuándo solo encapsula SQL que viviría mejor en el código.

Revisión de la relación entre procedimientos, seguridad, plan cache y gobernanza del motor.

Construcción de wrappers limpios para procedimientos usados de forma intensiva en dominios corporativos.

Trabajo sobre resultados únicos, múltiples y mixtos devueltos por procedimientos.

Preparación de tests y documentación mínima de contratos proc-código.

Revisión de errores frecuentes con tipos, direcciones de parámetro y manejo de nulos.

Taller de integración seria de stored procedures con Dapper.

Diseño de una disciplina de escritura SQL que permita a Dapper brillar sin convertir la capa de datos en un vertedero de strings.

Revisión de estrategias para mantener SQL embebido, externalizado o generado parcialmente según el tipo de proyecto.

Trabajo sobre indentación, aliases, CTEs, naming y shape de consulta pensados para mantenimiento.

Preparación de convenciones para filtros, joins, ordenaciones y paging consistentes a nivel de equipo.

Detección de smells en consultas largas: repetición, ambigüedad, exceso de dinámica o dependencia de nombres pobres.

Revisión de cuándo merece la pena encapsular fragmentos y cuándo hacerlo empeora la legibilidad.

Construcción de estándares internos para SQL en repositorios, query objects y handlers.

Trabajo sobre comentarios mínimos, estructura y separación entre SQL operativo y SQL de reporting.

Preparación de un catálogo de patrones de consulta reutilizables.

Taller de refactor de SQL heredado hacia un estándar de equipo.

Uso de Dapper.SqlBuilder como componente oficial para construir consultas dinámicas de forma componible.

Revisión de escenarios donde el SQL dinámico es inevitable: filtros opcionales, búsqueda avanzada, módulos de reporting y backoffice.

Trabajo sobre cómo montar `SELECT`, `WHERE`, `ORDER BY` y bloques opcionales sin concatenación descontrolada.

Preparación de una capa de builders que mantenga seguridad de parámetros y legibilidad razonable.

Detección de cuándo el builder ayuda y cuándo una query estática con pequeñas ramas resulta más simple.

Revisión de composición por fragmentos y de la necesidad de mantener ownership claro del SQL resultante.

Construcción de estrategias reutilizables para búsquedas multi-criterio en APIs y administración.

Trabajo sobre testeo del SQL generado y verificación de parámetros asociados.

Preparación de patrones para filtros opcionales sin caer en consultas monstruosas.

Taller de implementación completa de un buscador avanzado con Dapper.SqlBuilder.

Revisión profunda de `DbTransaction` y de cómo usarla con Dapper para operaciones atómicas.

Trabajo sobre la diferencia entre agrupar comandos por comodidad y agruparlos por necesidad real de consistencia.

Preparación de transacciones explícitas en comandos que afectan varias tablas o varios pasos de negocio.

Detección de errores habituales al olvidar propagar la misma transacción a todos los comandos involucrados.

Revisión de rollback, manejo de excepciones y comportamiento esperado ante fallos intermedios.

Construcción de una estrategia de fronteras transaccionales razonables en servicios y handlers.

Trabajo sobre consistencia, idempotencia y reintentos cuando el sistema interactúa con colas o servicios externos.

Preparación de operaciones críticas con lectura, escritura y logging bajo una misma garantía transaccional cuando proceda.

Revisión de alternativas para simplificar uso de transacciones en código repetitivo.

Taller de diseño de una operación compleja con Dapper y transacciones.

Comprensión de por qué Dapper sigue siendo especialmente valorado por rendimiento frente a ORMs más pesados.

Revisión de los benchmarks públicos del propio proyecto y de cómo leerlos sin dogmatismo.

Trabajo sobre los costes reales en una query: red, base de datos, plan de ejecución, materialización y allocations.

Preparación de una metodología para optimizar donde de verdad importa y no solo en microdetalles del mapper.

Detección de consultas lentas que no se arreglan por usar Dapper, sino por mejorar SQL e índices.

Revisión de buffering, shape del resultado y uso de tipos simples o compuestos desde la óptica del rendimiento.

Construcción de una cultura de benchmark y profiling razonable para servicios de alta carga.

Trabajo sobre cuándo usar Dapper como fast path en una arquitectura híbrida.

Preparación de comparativas entre acceso manual ADO.NET, Dapper y otras opciones del stack .NET.

Taller de análisis y optimización de una operación crítica apoyado en métricas.

Revisión crítica de cómo encapsular Dapper sin destruir sus ventajas ni exponerlo de forma caótica.

Trabajo sobre repositorios pragmáticos frente a repositorios genéricos vacíos de sentido.

Preparación de query objects y command handlers con SQL explícito y bien localizado.

Construcción de capas de aplicación que orquesten negocio y persistencia con responsabilidades claras.

Revisión del encaje natural de Dapper en arquitecturas CQRS, sobre todo en el lado de consultas.

Detección de anti-patrones como un “DbService” genérico que mezcla todo tipo de queries y comandos sin orden.

Trabajo sobre contratos de lectura, DTOs, modelos de escritura y SQL especializado por caso de uso.

Preparación de una arquitectura híbrida donde Dapper conviva con EF Core cuando tenga sentido.

Revisión del equilibrio entre abstracción útil y proximidad al SQL.

Taller de refactor arquitectónico de una solución .NET con acceso a datos desordenado.

Revisión de los companions oficiales o semioficiales más cercanos al ecosistema Dapper y de su propósito real.

Trabajo sobre Dapper.Contrib como colección oficial de helpers CRUD y sobre el tipo de escenarios donde puede ahorrar tiempo.

Revisión de Dapper.Rainbow como micro-ORM por encima de Dapper y de sus límites en proyectos complejos.

Análisis de cuándo un helper CRUD aporta velocidad y cuándo es mejor quedarse en SQL explícito.

Preparación de criterios para decidir si usar companions o mantener el proyecto solo con Dapper core.

Detección de riesgo de dependencia excesiva de helpers que encajan mal con dominios ricos o SQL muy específico.

Trabajo sobre mantenimiento, gobernanza y prudencia al introducir paquetes satélite en sistemas corporativos.

Preparación de patrones de adopción selectiva para catálogos pequeños o módulos administrativos.

Revisión de por qué el núcleo del curso sigue centrado en Dapper y no en ocultarlo detrás de helpers.

Taller de evaluación de companions sobre casos concretos del negocio.

Comprensión de Dapper.AOT como tooling de build-time que intercepta código existente y lo reemplaza por implementaciones ahead-of-time.

Revisión de los beneficios potenciales: menos reflexión en runtime, más guidance sobre uso y mejor encaje en escenarios modernos de optimización.

Trabajo sobre qué tipos de proyectos justifican explorar Dapper.AOT y cuáles aún funcionan perfectamente con Dapper clásico.

Preparación de una estrategia de adopción progresiva para servicios sensibles a cold start, trimming o entornos muy controlados.

Detección de limitaciones y escenarios donde parte del runtime de Dapper sigue estando presente.

Revisión de cómo Dapper.AOT genera código y de por qué se parece conceptualmente a ADO.NET escrito a mano.

Trabajo sobre SQL syntax analysis y reglas de diagnóstico del ecosistema AOT.

Preparación de un laboratorio para evaluar Dapper.AOT sin imponerlo inmediatamente a toda la solución.

Revisión de bulk copy con Dapper.AOT y de los casos donde el proveedor lo soporta.

Taller de incorporación controlada de Dapper.AOT a un servicio .NET 10.

Diseño de una capa de observabilidad que permita saber qué consulta falló, cuánto tardó y con qué contexto de negocio.

Revisión de logging de SQL, tiempos de ejecución, correlación con request IDs y trazas distribuidas.

Trabajo sobre cómo registrar lo suficiente para operar sin exponer datos sensibles ni inundar el sistema de ruido.

Preparación de diagnósticos para timeouts, deadlocks, errores de conexión y shape inesperado de resultados.

Detección de puntos ciegos típicos cuando se usa Dapper sin ninguna estrategia de tracing.

Revisión de integración con `ILogger`, OpenTelemetry u otras capas corporativas de observabilidad.

Construcción de wrappers o middlewares ligeros para medir acceso a datos sin ocultar el SQL real.

Trabajo sobre alertado básico y SLAs de latencia para queries críticas.

Preparación de una disciplina de troubleshooting para entornos de producción.

Taller de instrumentación de un módulo Dapper con logging y métricas útiles.

Revisión de por qué Dapper no protege de malas decisiones si se usa SQL dinámico sin disciplina.

Trabajo sobre parametrización obligatoria como primera línea de defensa contra inyección.

Preparación de SQL dinámico seguro cuando realmente hace falta composición.

Detección de riesgos en interpolación, concatenación, literales y condiciones opcionales mal construidas.

Revisión de secretos, cadenas de conexión y rotación de credenciales en aplicaciones .NET 10.

Trabajo sobre mínimo privilegio en usuarios de base de datos y separación de contextos de lectura/escritura.

Preparación de prácticas seguras para procedimientos, vistas y access patterns sensibles.

Revisión de redacción de logs para no exponer credenciales ni payloads peligrosos.

Construcción de un marco de seguridad razonable alrededor del uso de Dapper.

Taller de revisión de seguridad sobre una capa de acceso a datos real.

Comprensión de que Dapper es ligero, pero los proveedores y dialectos SQL siguen importando muchísimo.

Revisión de diferencias prácticas entre SQL Server, PostgreSQL y SQLite en parámetros, sintaxis y comportamiento transaccional.

Trabajo sobre cómo escribir SQL portable cuando merece la pena y cómo aceptar SQL específico cuando el valor compensa.

Preparación de un estilo de proyecto que no confunda Dapper con independencia total del motor.

Detección de puntos donde el proveedor condiciona rendimiento, locking, paging o funciones disponibles.

Revisión de tipos, fechas, arrays, JSON y otros elementos que cambian según base de datos.

Construcción de criterios para separar SQL común de SQL provider-specific.

Trabajo sobre testing por proveedor cuando la organización opera con varios motores.

Preparación de módulos de persistencia conscientes del dialecto y de sus capacidades reales.

Taller de adaptación de consultas entre distintos proveedores relacionales.

Revisión de la importancia de testear Dapper con bases reales o entornos lo bastante fieles, y no solo con mocks.

Trabajo sobre fixtures de base de datos, datos de prueba, seeds y aislamiento de casos.

Preparación de tests de integración para lecturas, escrituras, transacciones y errores esperables.

Detección de falsos positivos cuando se testea solo el método, pero no el SQL ni su contrato real con la base.

Revisión de estrategias de limpieza de base y repetibilidad del entorno entre ejecuciones.

Construcción de una política de tests mínima y sostenible para proyectos con mucha lógica SQL.

Trabajo sobre snapshots de resultados, asserts por shape y validación de cardinalidad.

Preparación de pruebas para procedimientos, QueryMultiple, multi-mapping y operaciones bulk.

Revisión de herramientas útiles para levantar entornos efímeros o de laboratorio en CI.

Taller de diseño completo de estrategia de testing para una solución Dapper.

Revisión de cómo introducir Dapper sin romper proyectos existentes ni obligar a una reescritura total.

Trabajo sobre extracción progresiva de queries críticas desde repositorios antiguos o data access layers heredadas.

Preparación de una convivencia temporal entre Dapper y otros mecanismos de persistencia.

Detección de módulos donde el retorno del cambio es alto y de otros donde conviene no tocar todavía.

Revisión de cómo traducir patterns de EF a una mentalidad de SQL explícito sin perder claridad de negocio.

Construcción de un plan de adopción incremental por bounded context, endpoint o caso de uso.

Trabajo sobre minimización de riesgo en proyectos legacy con muchos procedimientos o SQL incrustado.

Preparación de métricas para demostrar si la adopción está mejorando rendimiento, simplicidad o control.

Revisión de trampas frecuentes al migrar demasiado rápido sin redefinir estándares.

Taller de roadmap de migración desde otro enfoque de persistencia hacia Dapper.

Selección de un caso real de API, servicio de aplicación, módulo CQRS o proceso batch donde Dapper tenga sentido pleno.

Diagnóstico del estado actual de acceso a datos, SQL, transacciones, observabilidad y puntos críticos del flujo.

Diseño de la arquitectura completa del módulo con conexiones, servicios, queries, commands y contratos de lectura.

Construcción de consultas básicas, avanzadas, multi-mapping y `QueryMultiple` según necesidad real del caso.

Implementación de parámetros complejos, transacciones, logging y manejo de errores con estándar profesional.

Incorporación selectiva de SqlBuilder, companions o Dapper.AOT cuando el caso lo justifique.

Validación de rendimiento y legibilidad del SQL sobre escenarios de uso real.

Diseño de tests de integración y de una estrategia de despliegue segura del módulo.

Presentación del caso con enfoque técnico, operativo y de mantenimiento futuro.

Entrega de un blueprint reusable para usar Dapper en otros servicios o módulos .NET 10.