¿Es ORM un antipatrón? [cerrado]

Tuve una discusión muy estimulante e interesante con un colega sobre ORM y sus pros y contras. En mi opinión, un ORM es útil solo en los casos más raros. Al menos en mi experiencia.

Pero no quiero enumerar mis propios argumentos en este momento. Entonces te pregunto, ¿qué opinas sobre ORM? ¿Cuáles son los pros y los contras?

Hay un conjunto bastante grande y variado de dificultades conceptuales y técnicas cuando se trata de abordar una base de datos relacional desde un ángulo orientado a objetos. Estas dificultades se conocen colectivamente como desajuste de impedancia relacional de objetos y el artículo relacionado de Wikipedia es extremadamente informativo. El artículo identifica bastantes, no veo ninguna forma sensata de describirlos aquí. Solo para darle una idea general, se catalogan como:

• Desajustes
  • Conceptos orientados a objetos
  • Diferencias de tipo de datos
  • Diferencias estructurales y de integridad.
  • Diferencias manipuladoras
  • Diferencias transaccionales
• Resolver desajustes de impedancia
  • Minimización
  • Arquitecturas alternativas
  • Compensación
• Contención
• Diferencias filosóficas

Creo que si se toma el tiempo de leer el artículo, comprenderá que el hecho de que ORM a veces se describa como un antipatrón es de hecho inevitable. Los dos dominios son tan diferentes que cualquier enfoque para tratar uno como el otro es, por defecto, un antipatrón, en el sentido de que un antipatrón es un patrón que va en contra de la filosofía de un dominio.

Pero no creo que el término deba aplicarse a nada que esencialmente actúe como un puente entre dos dominios muy diferentes. Etiquetar un patrón como antipatrón solo tiene sentido dentro de su dominio. Entonces la pregunta de si es un antipatrón o no es irrelevante.

¿Pero es útil? Sí, ORM es uno de los antipatrones más útiles que existen. Comprenderá por qué solo si se encuentra en una situación práctica en la que tendrá que intercambiar bases de datos en un proyecto. O incluso actualizar a otra versión de la misma base de datos. ORM es una de esas cosas, que solo entiendes completamente cuando realmente las necesitas.

Por supuesto, como todo lo útil, ORM es muy propenso al abuso. Si cree que de alguna manera reemplaza la necesidad de saber todo sobre la base de datos en la que trabaja, volverá y lo morderá. Difícil.

Finalmente, permítanme descaradamente conectar otra de mis respuestas , en el relacionado "¿El patrón ActiveRecord sigue / fomenta los principios de diseño SOLID?" pregunta, que para mí es una pregunta mucho más relevante que "es un antipatrón".

Esto es similar a preguntar "¿un taladro eléctrico es un antipatrón?". Los ORM obtuvieron un buen lugar en mi caja de herramientas, reduciendo mi código repetitivo y todavía puedo usar SQL personalizado si es necesario. Entonces, si es un antipatrón, ¿contra qué patrón va?

Mi respuesta es no, hay muchos ORM maduros que hacen que su vida sea mucho más fácil y que su código sea más comprensible. Esto de alguna manera significa que no necesita comprender SQL, sino todo lo contrario.

Me atrevería a llamar a algo "antipatrón", que Martin Fowler llamó primero un patrón y que desde entonces ha sido adoptado en casi todos los lenguajes de programación modernos. (Consulte el artículo de Wikipedia sobre ActiveRecord ).

Un buen ORM puede generar mucho menos código (y mucha menos repetición) en un proyecto, y nada está tan fuertemente relacionado con los errores como la cantidad de código original.

Los ORM generalmente están diseñados para manejar los casos de uso más comunes para trabajar con bases de datos. Es posible que las consultas complejas aún necesiten escribirse explícitamente. Pero no recomendaría escribir consultas explícitas para cada interacción de la base de datos. En la mayoría de los casos, eso es una pérdida de tiempo.

Usar un ORM en lugar de aprender SQL es una muy mala idea. Si no sabe exactamente el tipo de SQL que se genera, si no comprende los problemas de N + 1 y cómo optimizar, definitivamente causará más daño que bien. Sin embargo, siento que soy mucho más productivo usando un ORM. Prefiero Rails ActiveRecord, que no intenta fingir que no hay una base de datos y no se interpone en su camino si solo necesita escribir SQL. Sin embargo, me preocupa que algunas personas puedan confiar en los modismos que ven demasiado profundamente, sin una comprensión profunda de lo que están haciendo.

Mi experiencia: estoy usando NHibernate con Linq2NHibernate.

Pros:

• Se deshace de "Magic Strings", o al menos ofrece un lugar único para colocarlos.
• Me permite trabajar en un paradigma OO todo el tiempo
• El código es más fácil de leer.
• El código construido en la parte superior es más fácil de cambiar.
• Le permite intercambiar su base de datos relacional real sin mantener 2 repositorios separados (rara vez se hace, pero ese es un gran beneficio si lo necesita).

Contras:

• El código es más difícil de escribir , porque
• No es una abstracción suficiente: aún debe estar íntimamente familiarizado con lo que está haciendo en segundo plano.

Diré que no cumple con la promesa que la mayoría de la gente inicialmente espera. No culparía a alguien por decir que es un antipatrón. En mi caso, encuentro que todavía necesito hacer pruebas de integración contra una base de datos SQLite para asegurarme de que mis consultas Linq2NHibernate realmente funcionen. Entonces, realmente, si estás haciendo pruebas de integración contra una base de datos relacional real de todos modos, eso elimina el problema con las "cadenas mágicas".

Si tuviera que comenzar un nuevo proyecto, no estoy seguro de si usaría un ORM o no. Probablemente lo haría, pero no puedo decir con certeza que debas hacerlo. Yo diría que es la diferencia entre elegir C ++ o Java / .NET para su proyecto: ¿necesitará la flexibilidad que obtiene al trabajar en un nivel inferior, o prefiere trabajar en un nivel superior y (supuestamente) será más? ¿productivo? La respuesta normal es trabajar a un nivel lo más alto posible . Eso generalmente significa usar un ORM.

La fortaleza de un ORM es que le permite modelar el comportamiento de la aplicación utilizando técnicas orientadas a objetos. En un mundo cuidadosamente diseñado, tiene una capa de la aplicación donde el idioma de la empresa se combina perfectamente con el idioma del equipo de desarrollo. El ORM es un habilitador de eso, si el ORM se usa con sensatez.

La debilidad es que la cantidad de personas que realmente obtienen una programación orientada a objetos es bastante pequeña. Mucha gente escribe espaguetis y albóndigas, con objetos altamente acoplados que tienen poco comportamiento propio y el comportamiento real termina en clases horribles de "Servicio" y "Gerente" de 8000 líneas, y ese código a menudo es tan complicado que todos tienen miedo de cambiarlo porque no pueden descubrir cuáles serán los efectos secundarios.

Además, mucha gente realmente no entiende el modelo relacional. Un ORM no los ayudará a obtenerlo, y no los ayudará abstrayendo el modelo relacional. Simplemente le permite concentrarse en su capa de dominio desde el principio y hacerlo bien antes de comenzar a preocuparse demasiado por el diseño de la base de datos. Si se aplica bien, con la ayuda de herramientas de migración de esquemas sensatas, y ORM puede ayudarlo a evitar que se acumule la deuda del código.

He creado aplicaciones en las que un ORM mantuvo el código de la aplicación simple, legible y comprobable, y tuvo un rendimiento razonable. También mantuve aplicaciones donde el patrón fue mal utilizado y el código fue complicado, no comprobable, lento y frágil; Resulta que el ORM en sí tenía poco que ver con esto, excepto que en lugar de escribir un código incorrecto que modelaba mal el dominio de la aplicación, el equipo de ingeniería heredado escribió un código incorrecto que modelaba mal el dominio de la aplicación Y un código de capa de servicio incorrecto que descuidaba todo El valor que su ORM podría proporcionarles.

Los ORM no lo harán más inteligente, pero en manos del desarrollador adecuado, puede conducir a un código más mantenible y de mayor calidad.

Quizás la respuesta esté en el reverso de su pregunta: ¿es una buena idea almacenar los datos de su aplicación en algo que no sea ​​una base de datos relacional? ¿Qué problemas está eliminando y qué otros problemas resolverá? ¿Puede vivir sin la capacidad de hacer una referencia cruzada fácil de sus datos (uniones) o filtrar rápidamente los registros que desea en función de múltiples criterios? ¿No necesita un soporte sólido para transacciones (suponiendo que su alternativa no lo tenga)? No todas las aplicaciones necesitan un almacén de datos siempre consistente y completo.

Creo que el antipatrón real aquí puede estar usando una base de datos relacional cuando no la necesita. Si necesita uno, entonces necesita ORM, y definitivamente no es un antipatrón.

ORM es una herramienta. Como todas las herramientas, cuando se usan adecuadamente, funcionan bastante bien. Cuando se usa de manera inapropiada, necesita un martillo más grande y algo de cinta adhesiva.

En el caso del proyecto actual en el que estoy trabajando, será mantenido por no desarrolladores (ingenieros mecánicos, para ser precisos) y, por lo tanto, debe ser simple y fácil de entender. Pasarán varios años antes de que este grupo tenga un presupuesto para contratar desarrolladores (suponiendo que el próximo presidente no elimine la agencia involucrada), por lo que las capacidades de mantenimiento futuro son un factor importante en nuestras consideraciones.