Tuve una conversación muy estimulante e interesante con un colega sobre ORM y sus ventajas y desventajas. 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. Así que 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 al tratar de acercarse a una base de datos relacional desde un ángulo orientado a objetos. Estas dificultades se conocen colectivamente como desajuste de impedancia relacional del objeto y el artículo relacionado de Wikipedia es extremadamente informativo El artículo identifica algunos, no veo ninguna forma sensata de describirlos aquí. Solo para darles una idea general, están catalogados como:
- desajustes
- Conceptos orientados a objetos
- diferencias de tipo de datos
- Diferencias estructurales e integridad
- diferencias de manipulación
- diferencias transaccionales
- Resolviendo el desajuste de impedancia
- Minimización
- arquitecturas alternativas
- Compensación
- contención
- diferencias filosóficas
Creo que si te tomas el tiempo de leer el artículo, entenderás que el hecho de que el 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 anti-patrón solo tiene sentido dentro de su dominio. Así que la pregunta de si es un anti-patrón o no es irrelevante.
¿Pero es útil? Sí, ORM es uno de los anti-patrones más útiles que existen. Solo entenderá por qué 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 cuando las necesitas.
Por supuesto, como todo lo útil, ORM es altamente propenso al abuso. Si crees que de alguna manera reemplaza la necesidad de saber todo sobre la base de datos en la que trabajas, entonces volverá y te morderá. Difícil.
Por último, permítame enchufar descaradamente otra de mis respuestas , en la página " ¿El patrón ActiveRecord sigue / fomenta los principios de diseño SOLID? ", que para mí es una pregunta mucho más relevante que" es un antipatrón ".
Esto es como preguntar "¿es un taladro eléctrico un antipatrón?". Los ORM ganaron un buen lugar en mi caja de herramientas, reduciendo el código de mi plantilla y todavía puedo usar SQL personalizado si es necesario. Entonces, si es un anti-patrón, ¿contra qué patrón va?
Mi respuesta es no, hay muchos ORM maduros que hacen su vida mucho más fácil y hacen que su código sea más comprensible. Esto significa que no es necesario que comprenda SQL, sino todo lo contrario.
Yo dudaría en llamar a algo un "anti-patrón" que fue llamado por primera vez un patrón por Martin Fowler y desde entonces ha sido adoptado en casi todos los lenguajes de programación modernos. (Vea el artículo de Wikipedia sobre ActiveRecord .)
Un buen ORM puede generar mucho menos código (y mucho menos repetición) en un proyecto, y nada tiene una correlación tan fuerte con los errores como la cantidad del 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. Las consultas complejas pueden necesitar ser escritas explícitamente. Pero no recomendaría escribir consultas explícitas para cada interacción de base de datos. En la mayoría de los casos, es una pérdida de tiempo.
Usar un ORM en lugar de aprender SQL es una idea bastante mala. Si no sabe exactamente el tipo de SQL que se genera, si no comprende los problemas de N + 1 y cómo optimizarlos, definitivamente causará más daño que beneficio. Sin embargo, siento que soy mucho más productivo usando un ORM. Prefiero Rails ActiveRecord, que no trata de fingir que no hay una base de datos y que no te estorba si solo necesitas escribir SQL. Sin embargo, me preocupa que algunas personas confíen 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:
Contras:
Diré que no cumple la promesa que inicialmente la mayoría de las personas esperan. No culparía a alguien por decir que es un anti-patrón. Encuentro, en mi caso, que todavía necesito hacer pruebas de integración contra una base de datos SQLite para asegurarme de que mis consultas de Linq2NHibernate realmente funcionan. Entonces, realmente, si estás haciendo pruebas de integración contra una base de datos relacional real, eso elimina el problema con "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 seguridad que usted debería hacerlo. Diría que es como la diferencia entre elegir C ++ o Java / .NET para su proyecto: ¿va a necesitar la flexibilidad que obtiene al trabajar en un nivel inferior, o preferiría trabajar en un nivel superior y (supuestamente) ser más ¿productivo? La respuesta normal es trabajar en un nivel tan alto como puede salirse con la suya . Eso generalmente significa usar un ORM.
La fuerza 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 lenguaje de la empresa se encuentra 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 en realidad termina en horribles clases de "Servicio" y "Administrador" de 8000 líneas, y ese código a menudo es tan complejo que todos temen de cambiarlo porque no pueden averiguar cuáles serán los efectos secundarios.
Además, muchas personas realmente no obtienen el modelo relacional. Un ORM no los ayudará a obtenerlo, y no los ayudará al abstraer el modelo relacional. Simplemente le permite centrarse en la capa de su 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 razonables, ORM puede ayudarlo a evitar que se acumulen las deudas de código.
He creado aplicaciones en las que un ORM mantuvo el código de la aplicación simple, legible, comprobable y con un rendimiento razonable. También he mantenido aplicaciones en las que el patrón se usó incorrectamente 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 nivel de servicio incorrecto que descuidaba todos el valor que su ORM podría proporcionarles.
Los ORM no lo harán más inteligente, pero en las manos del desarrollador adecuado, puede llevar a un código más mantenible y de mayor calidad.
Quizás la respuesta se encuentra en el reverso de su pregunta: ¿es una buena idea almacenar los datos de su aplicación en algo distinto que no sea una base de datos relacional? ¿Qué problemas está eliminando y qué otros problemas resolverá? ¿Puede vivir sin la capacidad de cruzar fácilmente sus datos (uniones) o filtrar rápidamente los registros que desea en función de múltiples criterios? ¿No necesita un soporte de transacciones sólido (suponiendo que su alternativa no lo tiene)? No todas las aplicaciones necesitan un almacén de datos siempre consistente y completo.
Creo que el anti-patrón real aquí puede estar usando un DB relacional cuando no lo necesitas. Si necesita uno, entonces necesita ORM, y definitivamente no es un antipatrón.
ORM es una herramienta. Como todas las herramientas, cuando se usan apropiadamente, funcionan bastante bien. Cuando se usa inadecuadamente, necesita un martillo más grande y algo de cinta adhesiva.
En el caso del proyecto actual en el que estoy trabajando, lo mantendrán quienes no sean desarrolladores (ingenieros mecánicos, para ser precisos), por lo que debe ser simple y fácil de resolver. Pasarán varios años antes de que este grupo tenga un presupuesto para contratar desarrolladores (suponiendo que el próximo Presidente no suprima a la agencia involucrada), por lo que las futuras capacidades de mantenimiento son un factor importante en nuestras consideraciones.
Lea otras preguntas en las etiquetas object-oriented design-patterns anti-patterns orm