¿Es ORM un antipatrón? [cerrado]

58

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?

derphil
fuente
3
¿Has leído esto: seldo.com/weblog/2011/08/11/orm_is_an_antipattern ?
FrustratedWithFormsDesigner
2
Si. A menos que tenga una aplicación CRUD genérica que no haga nada de valor con la base de datos, en cuyo caso no debería usar una base de datos relacional.
Raynos
1
@derphil: es posible que desee que sea menos amplio, de lo contrario, esto se cerrará. Si cree que ES un antipatrón, quizás explique por qué y luego pregunte en qué situaciones es apropiado este antipatrón (pero eso podría ser demasiado amplio).
FrustratedWithFormsDesigner
2
@derphil, hay muchos contraargumentos en los comentarios a esa publicación de blog, ¿los has leído?
Péter Török
2
Y solo otra evidencia de por qué no necesita un ORM: medium.com/@wrong.about/you-dont-need-an-orm-7ef83bd1b37d
Zapadlo

Respuestas:

83

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".

Yannis
fuente
55
+1 por trabajar en la frase "falta de coincidencia de impedancia". Palabras de moda para geeks, ¡pero también me gustan!
2011
Totalmente de acuerdo ... verifique que este enlace está muy bien explicado: seldo.com/weblog/2011/08/11/orm_is_an_antipattern
sandino
42

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.

Otávio Décio
fuente
11
+1 Yo también creo que es muy útil, hay una curva de aprendizaje. Pero es muy agradable no tener que rellenar pojos manualmente, etc.
NimChimpsky
18

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.

Nathan Long
fuente
12
"
Dudaría
3
@Raynos: ¿Quieres decir ... estás diciendo ... que Fowler podría haber estado ... equivocado? shock y jadeo Herejía! ¡¡Blasfemia!! : P;)
FrustratedWithFormsDesigner
99
@Raynos - Quizás la autoridad no sea el mejor argumento, pero el OP dijo "en mi experiencia". Esto es esencialmente una apelación a la autoridad personal, por lo que creo que es razonable contrarrestar con una apelación a la autoridad y al consenso. Además, el término "antipatrón" se refiere a las opiniones. He dado ejemplos de lo que piensan otras personas.
Nathan Long
3
@NathanLong Solo estaba señalando que la popularidad y la corrección son ortogonales.
Raynos
1
FWIW Data Mapper es probablemente el patrón que más se asigna a un ORM. ActiveRecord es un patrón diferente, aunque ciertamente relacionado.
JasonTrue
11

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.

Jeremy
fuente
11

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.

Scott Whitlock
fuente
6

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.

JasonTrue
fuente
Creo que esto confunde el uso de un ORM como patrón para el acceso a la base de datos y un ORM como un generador de código elegante para hacer que el acceso a la base de datos sea más fácil y mejor.
gbjbaanb
No estoy seguro de lo que quieres decir con eso. Tu comentario no tiene mucho sentido para mí.
JasonTrue
En ese sentido, un ORM es una excelente manera de acceder a un DB con un montón de trabajo duro hecho por usted, pero si lo usa como un patrón de diseño para fingir que un DB es una colección de objetos, comienza a caerse. Que es lo que pensé que estabas diciendo.
gbjbaanb
No creo haber defendido el uso de un ORM para pretender que tienes un almacén de objetos mágicos que no requiere que entiendas cómo funciona la base de datos. Dije exactamente lo contrario: si comprende bien la programación orientada a objetos Y cómo funcionan las bases de datos, un ORM puede ayudarlo a producir un código más fácil de mantener.
JasonTrue
5

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.

TMN
fuente
1
MIENTRAS estoy de acuerdo en que usar una base de datos relacional si no necesita una es una mala idea, ¡hoy en día si usa una necesita un ORM es ridículo!
HLGEM
1
Entonces, ¿cómo vas a introducir y sacar tus datos de la base de datos? En algún lugar, algo tendrá que asignar tus objetos a la estructura relacional y volver a crearlos cuando se lean desde la base de datos. Incluso si escribe consultas a mano y copia los datos dentro y fuera de los conjuntos de resultados, está haciendo ORM.
TMN
1
Usar procedimientos almacenados (la única forma aceptable de insertar cualquier tipo de información financiera por razones de control interno) para hacer toda la manipulación de la base de datos no es ORM en mi mente. Nunca he visto ningún valor para un ORM para alguien que realmente conoce bien SQL. Tampoco he trabajado en un sistema (y trabajo con aplicaciones empresariales muy complejas) que dependía mucho de un ORM, simplemente no son lo suficientemente buenos cuando lo que haces es complejo.
HLGEM
66
@HLGEM: ¿Y qué hay de los datos que obtienes de la base de datos? Cuando consulta la base de datos relacional, ¿no asigna los resultados a los objetos? En mi experiencia, hay dos tipos de proyectos que usan bases de datos relacionales: los que usan ORM de terceros y los que incluyen sus propios ORM mal construidos.
Carson63000
2
+1 Carson. Utiliza algún tipo de ORM sin importar qué, a menos que simplemente devuelva DataSets sin procesar y los aplique sobre su código (la ofensa más atroz de todo en mi humilde opinión) ya que siempre tendrá que asignar los resultados de ese procedimiento almacenado a las clases, que es exactamente lo que Los ORM lo hacen por ti.
Wayne Molina
4

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.

Tangurena
fuente