Hey estimados devs, aquí continuaré dando respuesta a las preguntas planteadas en este artículo.
Categoría 7: Miscelánea
27. Explica cómo funciona el middleware en ASP.NET Core.
En ASP.NET Core, un middleware es un componente que se ejecuta en el pipeline HTTP y que puede procesar la solicitud, modificarla o pasarla al siguiente middleware. Cada uno decide si continúa o corta el flujo.
Ejemplo típico: un middleware de autenticación valida el token JWT y, si es inválido, devuelve 401 Unauthorized sin llegar al controlador. Otro caso común es registrar métricas de tiempo de respuesta antes y después de la ejecución del siguiente middleware.
En proyectos grandes, es buena práctica crear middlewares personalizados para cross-cutting concerns como logging, validación de cabeceras o manejo centralizado de excepciones, en lugar de duplicar lógica en controladores, así que ya sabes qué responder, dev.
En este artículo te hablo a mayor detalle 👌🏼
28. Explica la diferencia entre IEnumerable, ICollection, IList e IQueryable en .NET.
Aquí anda al grano:
- IEnumerable: es un recorrido secuencial, solo lectura, sin operaciones de modificación. Ideal para LINQ to Objects.
- ICollection: extiende IEnumerable con métodos para contar, agregar y eliminar. Representa una colección en memoria.
- IList: hereda de ICollection y permite acceso indexado. Útil cuando importa la posición de los elementos.
- IQueryable: se usa para consultas diferidas hacia un proveedor de datos (EF Core, LINQ to SQL). Las expresiones se traducen a SQL o a otra fuente, optimizando la ejecución.
En la práctica, IEnumerable/ICollection/IList se usan para manejar datos en memoria, mientras que IQueryable es clave cuando queremos que la query se ejecute en la base de datos, evitando traer todo a memoria antes de filtrar, muy usado por ejemplo en paginación.
29. ¿Utilizaste alguna vez el Options pattern o inyección de configuración con IConfiguration? Explícamelo.
Si aún no has usado o no sabes qué es, aquí puedes aprenderlo, ¿Qué esperas? Corre 🏃🏼♂️➡️
Sí, ya que es una buena práctica. El Options Pattern permite mapear secciones de appsettings.json a clases fuertemente tipadas usando IOptions<T>. Esto evita leer valores con Configuration["Key"] en múltiples lugares y centraliza la configuración.
Ejemplo:
builder.Services.Configure<JwtSettings>(
builder.Configuration.GetSection("Jwt"));
Luego, cualquier servicio puede inyectar IOptions<JwtSettings> para acceder a los valores.
Este enfoque mejora la mantenibilidad y la testabilidad: en pruebas unitarias se pueden inyectar opciones mockeadas sin necesidad de cargar un archivo de configuración real.
30. Dame un ejemplo real en el que hayas aplicado alguno de los principios SOLID y por qué lo implementaste.
Un caso real fue al diseñar un servicio de notificaciones en un sistema de e-commerce. Inicialmente, una única clase enviaba correos, SMS y notificaciones push, violando el Single Responsibility Principle (SRP).
La refactorización separó cada canal en su propia implementación (EmailNotifier, SmsNotifier, PushNotifier), todas implementando una interfaz común INotifier. Luego se aplicó Dependency Inversion Principle (DIP): el servicio de pedidos dependía de INotifier, no de una implementación concreta.
Esto permitió extender el sistema fácilmente cuando la empresa integró WhatsApp como canal adicional, sin modificar el código existente. Ejemplo clásico de cómo SOLID reduce el costo de cambio en sistemas en evolución.
Hey, pero no te estoy diciendo que mientas ah, tú adáptalo a algún ejemplo que hayas hecho, sin embargo, esta respuesta real que te doy es para que sepas cómo podrías responder en una entrevista real, además puedes aplicarlo tú mismo ya que como te repito es un ejemplo real.
Pues bien, eso es todo, dev, uff, terminamos la entrevista! Ahora la pelotita está en tu cancha y comparte estos artículos, le invertí muchas horas a esto. 🐿️
Esto sí es cine, no humo 🤣
¡Si esta entrada te ha gustado, compártela ah!
Créditos de imágenes : Basada en Foto de Gerald Schömbs en Unsplash y Foto de Vitaly Gariev en Unsplash