Hey estimados devs, aquí continuaré dando respuesta a las preguntas planteadas en este artículo.

Categoría 3: Persistencia de datos y ORMs

11. ¿Cuáles son las ventajas y desventajas de Entity Framework Core frente a Dapper?

EF Core es un ORM que te da productividad y abstracción: puedes mapear entidades, usar LINQ, validaciones y migraciones automáticas. Es ideal para proyectos con lógica de negocio compleja y cambios frecuentes en el modelo de datos. La desventaja es que su rendimiento es menor al trabajar con consultas muy grandes o escenarios de alto volumen.

Dapper, en cambio, es un micro ORM que trabaja casi a la velocidad de ADO.NET. Te da control absoluto sobre las consultas y es excelente para lecturas masivas y reportes. La desventaja es que no ofrece migraciones ni tracking de entidades, y el código SQL lo escribes a mano, lo que puede aumentar el mantenimiento.

12. ¿Cómo manejarías la migración de una base de datos existente en EF Core con datos en producción?

Con EF Core no puedes simplemente “borrar y recrear” la base de datos en entornos con datos reales porque perderías toda la información.

Lo correcto es usar migraciones manuales: generas una migration (Add-Migration), la ajustas para reflejar la base real (quitando operaciones peligrosas como DropTable), y luego aplicas Update-Database.

Antes de hacerlo en producción, es importante respaldar la base y probar la migración en un entorno de staging con una copia de datos reales para asegurarte de que no rompa nada.

Otra alternativa segura es usar scripts SQL generados por EF Core (Script-Migration). Esto te permite revisar el SQL, ejecutarlo manualmente y aplicar solo los cambios validados, manteniendo control sobre la integridad y los datos productivos.

13. ¿Cómo manejarías el problema de N+1 en EF Core? ¿Y en Dapper? (Pregunta de rendimiento)

Para comenzar debes saber qué es el problema de N+1, ahora te lo explico:

El problema de N+1 consultas ocurre cuando, para obtener una lista de registros junto con sus datos relacionados, el sistema ejecuta una consulta principal (1) y luego N consultas adicionales (una por cada elemento de esa lista). Esto sucede cuando no usas la cláusula Include.

Ejemplo con EF Core sin Include:

var orders = context.Orders.ToList();  

foreach (var order in orders)  
{  
    var customer = order.Customer; // Aquí EF hace otra consulta por cada order  
}

• EF ejecuta 1 consulta para traer las órdenes.
• Luego, por cada orden (N), ejecuta otra consulta para traer al cliente.
• Si tienes 100 órdenes, terminas con 101 consultas: problema de N+1.

Esto degrada mucho el rendimiento.

En EF Core, el problema de N+1 se resuelve principalmente con:

• Eager Loading: usando .Include() y .ThenInclude() para cargar relaciones en una sola consulta.
• Proyecciones con Select: Cuando solo necesitas ciertos campos en lugar de todo el objeto.
• Opcionalmente, ajustar con .AsSingleQuery() (una sola consulta con JOINs) o .AsSplitQuery() (varias consultas controladas por EF Core) según convenga para el rendimiento y la complejidad de los datos.

En Dapper, el control está en tus manos porque escribes el SQL.

El problema N+1 lo evitarías así:

• Usando multi-mapping (Query<T1, T2, TResult>) y un JOIN para obtener entidades relacionadas en una sola consulta.
• También puedes dividir la carga en varias consultas optimizadas y combinarlas en memoria, lo que te da más flexibilidad que un ORM.

14. ¿Qué estrategias de resiliencia aplicarías al conectar con una base de datos?

Puedes investigar las siguientes para que las utilices:

Reintentos con backoff exponencial: volver a intentar operaciones fallidas con intervalos crecientes para evitar saturar la BD (por ejemplo, con Polly en .NET).

Circuit breaker: si los fallos persisten, detener temporalmente los intentos hasta que la base se recupere, protegiendo tanto al cliente como al servidor.

Pooling y timeouts: ajustar parámetros como MaxPoolSize y CommandTimeout para evitar conexiones colgadas o consumo excesivo de recursos.

Caching estratégico: cachear resultados de solo lectura (con Redis o MemoryCache) para reducir la carga en la base de datos.

Monitoreo y alertas: implementar logs, métricas y dashboards (Serilog + Application Insights / Grafana) para detectar y reaccionar ante degradaciones antes de que afecten al usuario.

Esto es todo por ahora, dev, en la siguiente entrada seguimos con la siguiente categoría! 🍖🐿️

¡Si esta entrada te ha gustado, compártela! 

Créditos de imagen de portada: Basada en Foto de Gerald Schömbs en Unsplash