ORM en el mundo real

Estoy comenzando un nuevo proyecto que creo que durará por algunos años. Estoy a punto de decidir el marco ORM para usar (o si usar uno en absoluto). ¿Alguien con experiencia puede decirme si los marcos de orm se usan en aplicaciones del mundo real? El problema que tengo en mente es este: la herramienta orm generará para mí tablas y columnas, etc. al crear y modificar mis entidades. Sin embargo, después de que el proyecto haya comenzado y esté en producción, ciertos cambios en la base de datos no serán posibles. ¿Puede esto obstaculizar el avance del proyecto? Si hubiera usado un framework como ibatis, por ejemplo, sé que solo necesitaría ajustar las sentencias SQL basadas en los cambios de la base de datos. ¿Puede alguien decirme si las herramientas ORM han sobrevivido al entorno en vivo? En mi oficina, utilizamos un ERP basado en Java que fue hecho hace mucho tiempo y nunca fue hecho usando ningún framework ORM.ORM en el mundo real

Atentamente. Josh

Fuente

2010-04-20 josh

Utilice solo esquemas generados automáticamente para el desarrollo temprano y creación de prototipos. El DDL generado casi nunca satisfará a ningún DBA experimentado. Además, la base de datos va a vivir correctamente más tiempo que el código de la aplicación actual, por lo que gastar tiempo en su diseño generalmente vale la pena el esfuerzo.

Al elegir un mapeador, elija uno flexible y manténgase alejado de los mapeadores obsesionados con objetos, ya que a menudo solo admiten la personalización limitada de la base de datos. Hiberna la pobre integración de procedimientos almacenados viene a la mente, al igual que la falta de compatibilidad de los JPA con los mapeadores de tipos personalizados.

mapeadores objeto como iBatis y EclipseLink son opciones seguras, ya que le permite asignar casi cualquier cosa, lo que garantiza que puede crear tanto un gran modelo de dominio y un ingenioso diseño de esquema. También tenga en cuenta que Spring JDBC ha recorrido un largo camino (en particular, el práctico SimpleJDBCTemplate), por lo que aunque técnicamente no es un ORM, le permite hacer todo lo que desee sin escribir tedioso código repetitivo JDBC.

Fuente

2010-04-20 09:08:55

Aclara por qué un marco ORM no debe estar "obsesionado con objetos" y cómo El marco ORM le permite "refactorizar el esquema de su base de datos". – ireddick

Un buen ORM debe satisfacer tanto a los DBA como a los desarrolladores de aplicaciones. Quiero tener un gran diseño de base de datos y un gran modelo de objetos. Los mapeadores como Hibernate fuerzan el diseño de la base de datos de una cierta manera, que me parece muy limitante. –

Esta respuesta aceptada expresa un punto de vista muy personal y no ilustra la percepción general del valor agregado de ORM y cuándo usarlos o no. En primer lugar, se supone que los ORM generan el SQL, lo que respalda los procedimientos almacenados es solo una instalación. Aún así, usar el procedimiento almacenado no es la filosofía de ORM (simplemente no use un ORM si está usando procedimientos almacenados). En segundo lugar, comparar Hibernate e iBATIS es como comparar manzanas y naranjas (sin mencionar Spring JDBC), iBATIS no es un ORM, es un mapeador de datos. Pero es cierto que los ORM no encajan bien con los esquemas esotéricos. –

He utilizado durante varios años en la producción Hibernate + JPA. Sin embargo, nunca he confiado en la generación del esquema ORM y creo que esta es una mala práctica en general ya que no tiene el control total del esquema de esta manera y ORM no siempre generará el esquema óptimo. Usando algo como Liquibase para rastrear migraciones de esquema en una idea mucho mejor IMO.

Fuente

2010-04-20 08:53:53

desde una perspectiva impulsada por el dominio, no debería necesitar tener el control del esquema. De hecho, no debería importar cómo exactamente se representa su modelo de dominio como un esquema relacional. – Bozho

Bozho, en el entorno de producción, le importa cómo su modelo de dominio se representa como una base de datos relacional. Una vez que haya puesto su aplicación en producción, ya no podrá realizar cambios en la base de datos como desee. En la mayoría de los casos, alguien más se hará cargo de la base de datos. – josh

@Bozho, la teoría y la práctica rara vez coexisten pacíficamente. Parece que hay errores en los ORM que generan un esquema incorrecto o no óptimo. También hay proyectos que usan ORMs que apuntan solo a un DB específico y los clientes insisten en usar todas las optimizaciones de DB posibles, no es bonito, pero ya sabes lo que dicen, el cliente siempre tiene la razón ... –

Los ORM se usan ampliamente en aplicaciones del mundo real. El problema del cambio de esquema que usted ha mencionado es típicamente tratado en una de dos maneras:

Como sugiere respuestas anteriores, se puede mantener el esquema manualmente en la base de datos y tienen actualizar el ORM su esquema para que coincida con lo que ve en la base de datos.
Puede hacer que el ORM compruebe el esquema de la base de datos contra su propia información sobre el modelo de objetos y genere las consultas necesarias para actualizar si ha habido algún cambio.

En mi experiencia, cualquier ORM decente debe ser capaz de manejar # 1 y la mayoría parecen ser capaces de manejar # 2, pero no es tan universal.

En cuanto a qué es mejor, bueno ... Eso depende mucho de cómo ve la relación entre su base de datos y su modelo de objeto.

Si su principal interés está en la base de datos y utiliza un ORM para proporcionar un OO envoltorio alrededor de las tablas y campos para hacerlos más accesibles, entonces probablemente quiera ir con # 1 y tener control total sobre la base de datos.

Si, por otro lado, ve el modelo de objetos como supremo y está utilizando principalmente la base de datos como un mecanismo de persistencia tonto, con el ORM que sirve para simplificar esa tarea, entonces probablemente desee usar # 2 para puede enfocarse en el modelo de objetos y no tener que preocuparse por los detalles de la base de datos. O tal vez quiera echar un vistazo a los almacenes de claves/valores, motores de persistencia de gráficos de objetos u otras formas de bases de datos NoSQL para obtener un mejor soporte para la persistencia de objetos sin tener que preocuparse por los cambios de esquema en el lado de la base de datos.

Fuente

2010-04-20 09:13:16

Gracias Dave. tengo algunos comentarios pensados. Si cambio la base de datos según su opción uno, tengo que actualizar mis metadatos de asignación: anotaciones o xml. prefiero las anotaciones y eso significaría recompilación y redespliegue. (cambio en la versión, proceso de control de calidad, etc.). Me encantaría evitar eso. – josh

He estado usando Hibernate durante algunos años, y estoy muy contento con él. Utilizo el generador de esquemas solo para crear una base de datos nueva, pero para las actualizaciones, uso scripts sintéticos hechos por el hombre.

No creo que sea posible automatizar confiablemente la actualización del esquema: si cambia el nombre de un campo, por ejemplo, una herramienta automática eliminaría el campo y agregaría uno nuevo, perdiendo así el contenido.

Fuente

2010-04-20 09:59:50

Respuesta

Cuestiones relacionadas