¿ORM sigue siendo un antipatrón?

• ORM (mapeador objeto-relacional) suele ser criticado como un antipatrón en el desarrollo de software.
• Sin embargo, esta crítica está exagerada, y los ORM no son inherentemente malos, igual que cualquier otra herramienta de software.
• El problema real de los ORM suele ser que se usan mal o se entienden mal.
• Como los ORM y las bases de datos relacionales operan bajo paradigmas distintos, pueden surgir desafíos complejos en el modelado de datos y las relaciones.
• Los ORM violan el principio de responsabilidad única (SRP) y el principio de separación de intereses (SOC), pero estas críticas no son en absoluto problemas definitivos.
• El problema real de los ORM está en la eficiencia y la visibilidad.
• Si no se usan correctamente, los ORM pueden ser ineficientes, pero cuentan con funciones que permiten optimizar consultas y mejorar el rendimiento.
• El problema N+1, en el que el ORM hace múltiples viajes de ida y vuelta a la base de datos, puede mitigarse usando un cargador de datos.
• El mayor problema de los ORM es la visibilidad y la depuración. Puede que no proporcionen mensajes de error claros o que dificulten entender y resolver los problemas.
• Cuando se usan correctamente, los ORM pueden ser tan eficientes como SQL puro, pero los desarrolladores deben aprovechar sus funciones y sus equivalentes de SQL nativo.
• En el caso de algunas consultas complejas o problemáticas, puede ser necesario cambiar a consultas SQL puras.
• En general, los ORM no son inherentemente malos, pero requieren un uso cuidadoso e informado para evitar problemas potenciales.

[GN⁺]

Opinión de Hacker News

• Se critican las limitaciones y desventajas de los ORM, por ejemplo la imposibilidad de usar otras bases de datos y la necesidad de conocer SQL.
• Se considera que un mejor enfoque es construir la capa de datos consulta por consulta, con interpolación de cadenas y de una forma cercana a JDBC puro.
• Los ORM a menudo se limitan al mapeo básico de tablas y vistas, ignorando funciones y capacidades avanzadas de SQL.
• Hay dos tipos de ORM: los que se basan en el modelo de dominio y los que generan el modelo de dominio a partir de una base de datos existente.
• Los ORM con distintas implementaciones y funciones, como jOOQ y Hibernate, se usan cada uno con propósitos diferentes.
• Los ORM pueden ser útiles en aplicaciones complejas con muchas tablas y relaciones de claves foráneas adecuadas.
• Usar SQL puro dentro de literales de cadena se considera una alternativa a los ORM, y también se pueden usar herramientas que generan wrappers de consultas.
• Se prefieren los ORM prácticos que no intentan ocultarlo todo dentro de un paquete ni introducir su propio lenguaje de consultas.
• SQLAlchemy recibe elogios por ofrecer una capa de consultas conveniente sin reinventar SQL.
• Si no se usa un ORM, los desarrolladores tienen que escribir y mantener su propia interfaz de base de datos, lo que puede generar bugs y vulnerabilidades de seguridad.
• La crítica de que los ORM violan los principios SOLID se considera un choque entre la enseñanza académica y el desarrollo real.
• La falta de experiencia o la influencia de prácticas académicas pueden causar problemas y sobrecostos.