ORM ainda é um antipadrão?

• ORM (mapeador objeto-relacional) costuma ser criticado como um antipadrão no desenvolvimento de software.
• No entanto, essa crítica é exagerada, e ORMs, como outras ferramentas de software, não são inerentemente ruins.
• Os problemas reais de ORM muitas vezes estão ligados a mau uso ou falta de compreensão.
• Como ORM e bancos de dados relacionais operam em paradigmas diferentes, podem surgir desafios complexos em modelagem de dados e relacionamentos.
• ORMs violam os princípios de responsabilidade única (SRP) e separação de preocupações (SoC), mas essas críticas não chegam a ser problemas decisivos.
• Os problemas reais de ORM estão na eficiência e na visibilidade.
• Quando não é usado corretamente, um ORM pode ser ineficiente, mas ele também oferece recursos para otimizar consultas e melhorar o desempenho.
• O problema de N+1, em que o ORM faz várias idas e voltas ao banco de dados, pode ser mitigado com o uso de data loaders.
• O maior problema dos ORMs é a visibilidade e a depuração. Eles podem não fornecer mensagens de erro claras ou dificultar a compreensão e a resolução de problemas.
• Quando usado corretamente, um ORM pode ser tão eficiente quanto SQL puro, mas os desenvolvedores precisam aproveitar seus recursos e equivalentes em SQL nativo.
• Em algumas consultas complexas ou problemáticas, pode ser necessário recorrer a consultas SQL puras.
• No geral, ORM não é inerentemente ruim, mas exige uso cuidadoso e conhecimento para evitar problemas potenciais.

[GN⁺]

Comentários do Hacker News

• As limitações e desvantagens de ORMs, como a impossibilidade de usar outro banco de dados e a exigência de conhecimento de SQL, são alvo de críticas.
• Construir a camada de dados consulta por consulta, com interpolação de strings e de uma forma próxima ao JDBC bruto, é visto como uma abordagem melhor.
• ORMs muitas vezes se limitam ao mapeamento básico de tabelas e views e ignoram recursos e capacidades avançadas do SQL.
• Existem dois tipos de ORM: os baseados em modelo de domínio e os que geram um modelo de domínio a partir de um banco de dados existente.
• ORMs com diferentes implementações e funcionalidades, como jOOQ e Hibernate, são usados para finalidades distintas.
• ORMs podem ser úteis em aplicações complexas com muitas tabelas e relações adequadas de chave estrangeira.
• Usar SQL bruto em literais de string é considerado uma alternativa aos ORMs, e também é possível usar ferramentas que geram wrappers de consulta.
• ORMs práticos, que não tentam esconder tudo em um pacote nem introduzem sua própria linguagem de consulta, são preferidos.
• O SQLAlchemy é elogiado por oferecer uma camada de consulta conveniente sem reinventar o SQL.
• Sem usar um ORM, os desenvolvedores precisam escrever e manter sua própria interface com o banco de dados, o que pode gerar bugs e vulnerabilidades de segurança.
• A crítica de que ORMs violam os princípios SOLID é vista como um conflito entre o ensino acadêmico e o desenvolvimento no mundo real.
• Problemas e estouros de orçamento podem ocorrer por falta de experiência ou pela influência de práticas acadêmicas.