DTO vs ORM: qual a diferença?
· 7 min
"DTO vs ORM" é uma forma comum de enunciar a dúvida, mas um pouco enganosa, os dois não são alternativas um ao outro. Um modela como o dado se move; o outro modela como o dado é persistido.
O que um ORM realmente faz
Um ORM (Object-Relational Mapper) mapeia linhas do banco pra objetos da linguagem, rastreia o estado desses objetos (dirty checking) e traduz chamadas de método em SQL. Ele vive na fronteira de persistência, entre o código da aplicação e o banco de dados.
O que um DTO realmente faz
Um DTO (Data Transfer Object) é uma estrutura simples e serializável, sem comportamento, usada pra mover um formato específico de dado através de uma fronteira, entre a camada de API e seus clientes, por exemplo, ou entre serviços. Ele existe pra desacoplar o que é exposto externamente do que é modelado internamente.
Por que expor a entidade do ORM direto é um problema
Serializar a entidade do ORM direto como resposta de API é um anti-padrão comum: vaza colunas internas que não deveriam ser públicas, relações carregadas de forma preguiçosa (lazy loading) podem disparar queries extras inesperadas durante a serialização, o clássico N+1, e qualquer mudança no schema do banco muda silenciosamente o contrato público da API.
Como os dois trabalham juntos
O fluxo típico: a requisição chega e é mapeada/validada como um DTO de entrada; a camada de serviço usa a entidade do ORM pra lógica de negócio e persistência; antes de responder, a entidade é mapeada de volta pra um DTO de saída (possivelmente com formato diferente do de entrada). Cada camada só conhece o formato que precisa conhecer.
Quando pular o DTO é aceitável
Em ferramentas internas pequenas ou protótipos, onde a API e o modelo de dados são genuinamente o mesmo formato e é improvável que divirjam, pular a camada de DTO é uma simplificação razoável. O custo do mapeamento só se paga quando os dois começam a precisar evoluir de forma independente.