DTO vs ORM: ¿cuál es la diferencia?
· 7 min
"DTO vs ORM" es una forma común de plantear la duda, pero un poco engañosa, los dos no son alternativas el uno del otro. Uno modela cómo se mueve el dato; el otro modela cómo se persiste.
Qué hace un ORM realmente
Un ORM (Object-Relational Mapper) mapea filas de la base de datos a objetos del lenguaje, rastrea el estado de esos objetos (dirty checking) y traduce llamadas a métodos en SQL. Vive en la frontera de persistencia, entre el código de la aplicación y la base de datos.
Qué hace un DTO realmente
Un DTO (Data Transfer Object) es una estructura simple y serializable, sin comportamiento, usada para mover un formato específico de dato a través de una frontera, entre la capa de API y sus clientes, por ejemplo, o entre servicios. Existe para desacoplar lo que se expone externamente de lo que se modela internamente.
Por qué exponer la entidad del ORM directamente es un problema
Serializar la entidad del ORM directamente como respuesta de API es un antipatrón común: filtra columnas internas que no deberían ser públicas, las relaciones cargadas de forma perezosa (lazy loading) pueden disparar queries extra inesperadas durante la serialización, el clásico N+1, y cualquier cambio en el esquema de la base de datos cambia silenciosamente el contrato público de la API.
Cómo trabajan juntos los dos
El flujo típico: la solicitud llega y se mapea/valida como un DTO de entrada; la capa de servicio usa la entidad del ORM para la lógica de negocio y la persistencia; antes de responder, la entidad se mapea de vuelta a un DTO de salida (posiblemente con un formato distinto al de entrada). Cada capa solo conoce el formato que necesita conocer.
Cuándo es aceptable saltarse el DTO
En herramientas internas pequeñas o prototipos, donde la API y el modelo de datos son genuinamente el mismo formato y es improbable que diverjan, saltarse la capa de DTO es una simplificación razonable. El costo del mapeo solo se justifica cuando los dos empiezan a necesitar evolucionar de forma independiente.