ORM Technologies vs JDBC?

Question

Mi pregunta es con respecto a las tecnologías ORM y JDBC, ¿con qué criterio elegiría una tecnología ORM en comparación con JDBC y de otro modo?

Gracias.

Answer 1

Complejidad.

ORM Si su aplicación es impulsada por un dominio y las relaciones entre objetos son complejas o necesita que este objeto defina lo que hace la aplicación.

JDBC/SQL Si su aplicación es lo suficientemente simple como para presentar datos directamente desde la base de datos o las relaciones entre ellos son bastante simples.

El libro "Los patrones de arquitectura de aplicación empresarial", de Martin Fowler explica mucho mejor las diferencias entre estos dos tipos:

Ver: Domain Model y Transaction Script

Answer 2

También depende de la curva de aprendizaje.

Ebean ORM tiene una curva de aprendizaje bastante bajo (API simple, lenguaje de consulta sencilla) si usted es lo suficientemente contento con anotaciones JPA para el mapeo (@Entity, @Table, @OneToMany etc).

Answer 3

JDBC

1. Con JDBC, el desarrollador tiene que escribir código para trazar la representación de datos de un modelo de objetos a un modelo de datos relacional y su correspondiente esquema de base de datos.
2. Con JDBC, la correlación automática de los objetos Java con las tablas de la base de datos y viceversa la debe encargar el desarrollador manualmente con líneas de código.
3. JDBC solo admite lenguaje de consulta estructurado (SQL) nativo. El desarrollador debe descubrir la forma eficiente de acceder a la base de datos, es decir, seleccionar consultas efectivas a partir de una serie de consultas para realizar la misma tarea.
4. Aplicación que utiliza JDBC para manejar datos persistentes (tablas de base de datos) que tienen código específico de base de datos en gran cantidad. El código escrito para asignar los datos de la tabla a los objetos de la aplicación y viceversa es en realidad asignar los campos de la tabla a las propiedades del objeto. A medida que cambia la tabla o se cambia la base de datos, es esencial cambiar la estructura del objeto así como también cambiar el código escrito para asignar table-to-object/object-to-table.
5. Con JDBC, es responsabilidad del desarrollador manejar el conjunto de resultados JDBC y convertirlo en objetos Java a través del código para usar estos datos persistentes en la aplicación. Entonces, con JDBC, la asignación entre los objetos de Java y las tablas de la base de datos se realiza de forma manual.
6. Con JDBC, el almacenamiento en caché se mantiene mediante codificación manual.
7. En JDBC no se verifica que siempre cada usuario tenga datos actualizados. Esta comprobación debe ser agregada por el desarrollador.

---

de hibernación.

1. Hibernate es la solución flexible y potente de ORM para asignar clases de Java a tablas de bases de datos. Hibernate se encarga de esta asignación usando archivos XML, por lo que el desarrollador no necesita escribir código para esto.
2. Hibernate proporciona persistencia transparente y el desarrollador no necesita escribir código explícitamente para mapear las tuplas de las tablas de la base de datos a los objetos de la aplicación durante la interacción con RDBMS.
3. Hibernate proporciona un poderoso lenguaje de consulta Hibernate Query Language (independiente del tipo de base de datos) que se expresa en una sintaxis similar a SQL familiar e incluye soporte completo para consultas polimórficas. Hibernate también es compatible con sentencias SQL nativas. También selecciona una forma efectiva de realizar una tarea de manipulación de la base de datos para una aplicación.
4. Hibernate proporciona esta asignación en sí. La asignación real entre las tablas y los objetos de la aplicación se realiza en archivos XML. Si hay un cambio en la base de datos o en cualquier tabla, entonces la única necesidad es cambiar las propiedades del archivo XML.
5. Hibernate reduce las líneas de código manteniendo la asignación de la tabla de objetos y devuelve el resultado a la aplicación en forma de objetos Java. Alivia al programador del manejo manual de datos persistentes, lo que reduce el tiempo de desarrollo y el costo de mantenimiento.
6. Hibernar, con persistencia transparente, la caché está configurada en el espacio de trabajo de la aplicación. Las tuplas relacionales se mueven a este caché como resultado de la consulta. Mejora el rendimiento si la aplicación cliente lee los mismos datos muchas veces para la misma escritura. La persistencia automática transparente le permite al desarrollador concentrarse más en la lógica comercial que en el código de esta aplicación.
7. Hibernate permite al desarrollador definir el campo de tipo de versión para la aplicación, debido a este campo definido Hibernate actualiza el campo de versión de la tabla de base de datos cada vez que la tupla relacional se actualiza en forma de objeto de clase Java a esa tabla. Entonces, si dos usuarios recuperan la misma tupla y luego la modifican y un usuario guarda esta tupla modificada en la base de datos, Hibernate actualiza automáticamente esta tupla. Cuando otro usuario intenta guardar la tupla actualizada en la base de datos, no permite guardarla porque este usuario no tiene datos actualizados.

Answer 4

creo que se olvidó de mirar a "Mapeo Relacional funcional"

me habría resumir diciendo:

• Si desea centrarse en las estructuras de datos, utilizar un ORM como JPA/Hibernate
• Si desea arrojar luz sobre los tratamientos, echar un vistazo a las bibliotecas FRM: QueryDSL o Jooq
• Si necesita ajustar sus requerimientos SQL en bases de datos específicas, utilice JDBC y SQL nativo solicita

La fuerza de varias tecnologías de "Mapeo relacional" es la portabilidad: se asegura de que su aplicación se ejecutará en la mayoría de las bases de datos de ACID. De lo contrario, lidiará con las diferencias entre varios dialectos SQL cuando escriba manualmente las solicitudes SQL.

Por supuesto que puede contenerse con el estándar SQL92 (y luego hacer algo de programación funcional) o se puede reutilizar algunos conceptos de la programación functionnal con ORM marcos

Los strenghs ORM se construyen sobre un objeto de sesión que puede actuar como un cuello de botella:

1. administra el ciclo de vida de los objetos, siempre que se esté ejecutando la transacción subyacente de la base de datos.
2. mantiene un mapeo uno a uno entre los objetos java y las filas de su base de datos (y utiliza un caché interno para evitar objetos duplicados).
3. que detecta automáticamente las actualizaciones de asociación y de los objetos huérfanos eliminar
4. que maneja cuestiones concurrenty con bloqueo optimista o pesimista.

Sin embargo, sus puntos fuertes son también sus puntos débiles:

1. La sesión debe ser capaz de comparar objetos por lo que necesita instrumentos es igual a métodos/hashCode pero los objetos igualdad debe tener sus raíces en "Claves de negocio "y no el ID de la base de datos (¡los nuevos objetos transitorios no tienen ID de base de datos!). Sin embargo, algunos conceptos reificados no tienen igualdad comercial (una operación, por ejemplo). Una solución común se basa en los GUID que tienden a molestar a los administradores de la base de datos.

2. La sesión debe espiar los cambios de relación, pero sus reglas de asignación impiden el uso de colecciones inadecuadas para los algoritmos de negocio. En algún momento le gustaría usar un HashMap pero el ORM requerirá que la clave sea otro "Objeto de dominio enriquecido" en lugar de otro ligero ... Luego debe implementar la igualdad de objeto en el objeto de dominio enriquecido que actúa como clave. .. Pero no se puede porque este objeto no tiene contraparte en el mundo de los negocios. Así que vuelve a una lista simple en la que debe iterar (y se producen problemas de rendimiento)

3. La API de ORM a veces no es apta para el uso en el mundo real. Por ejemplo, las aplicaciones web del mundo real intentan forzar el aislamiento de la sesión agregando algunas cláusulas "DONDE" cuando obtiene datos ... Luego, el "Session.get (id)" no es suficiente y debe pasar a una configuración más compleja DSL (HSQL, Criteria API) o volver a SQL nativo

4. Los objetos de la base de datos entra en conflicto con otros objetos dedicados a otros marcos (como OXM frameworks = Object/XML Mapping). Por ejemplo, si sus servicios REST utilizan la biblioteca de jackson para serializar un objeto comercial. Pero este Jackson se asigna exactamente a un Hibernate One. Entonces, o combinar ambos y un fuerte acoplamiento entre su API y su base de datos aparece o se le debe aplicar una traducción y todo el código que ha guardado desde el ORM se pierde allí ...

En el otro lado , FRM es una compensación entre "Asignación relacional de objetos (ORM) y consultas SQL nativas (con JDBC)

La mejor manera de explicar las diferencias entre FRM y ORM consiste en adoptar un enfoque DDD.

• Object Relational Mapping faculta el uso de "objetos de dominio rico", que son clases Java cuyos estados son mutables durante la transacción de base de datos
• Mapeo Relacional funcional se basa en "Objetos Pobre de dominio", que son inmutables (tanto usted tiene que clonar uno nuevo cada vez que se quiere alterar su contenido)

libera las restricciones impuestas a la sesión de ORM y se basa la mayor parte de tiempo en un DSL sobre el SQL (por lo que la portabilidad no importa) Pero, por otro lado, debe observar los detalles de la transacción, la concurrencia y emite

Lista de personas = queryFactory.selectFrom (persona) .where ( person.firstName.eq ("John"), person.lastName.eq ("Doe")) .fetch();