java - data - persistence.xml jpa mysql example

JDBC VS Hibernate

Question

Hemos estado usando JDBC durante mucho tiempo en nuestras aplicaciones web. La razón principal por la que lo usamos es porque tenemos el 100% de control sobre el código, sql y arreglamos las cosas con nuestras manos. Aparte de eso, usamos disparadores dentro de la base de datos, y la base de datos se desarrolla por separado por expertos de DB.

Sin embargo, ahora muchos recomiendan usar Hibernate así que también pensamos en usarlo. Pero, encontramos los siguientes problemas.

1. Hibernate no se puede conectar con una base de datos "Existente". Siempre trata de crear uno propio.

2. Nuestra base de datos puede acceder mediante la misma aplicación que se encuentra en diferentes plataformas (nube, servidor, VPS, computadora personal). Hibernate puede causar problemas debido a su almacenamiento en caché en esta situación.

3. Nunca nos gusta dar el "código de creación de trabajo" al código java. Creamos tablas de forma manual, siempre.

4. Podríamos tener que usar sentencias SQL muy largas y complejas. La última vez usamos una declaración con más de 150 líneas, uniendo más de 20 tablas. Dudamos si enfrentaremos problemas en esto cuando se trata de Hibernate.

5. Nuestro código SQL es bueno y estándar. El código generado por Hibernate parece estar un poco sucio para nosotros.

6. Siempre usamos MySQL. Nunca use ninguna otra base de datos.

7. La aplicación que creamos requiere una seguridad máxima, relacionada con la medicina. Si se ha filtrado al menos un registro de datos, hemos terminado.

8. Hay muchas foreign keys , foreign keys Primary Keys , Composite Keys , Unique Keys , etc. en la base de datos. En foros, algunos se quejaron de que Hibernate se metió con ellos.

9. Decidimos probar hibernar porque algunas personas dicen: "¿Son ingenieros de software? ¡Usan JDBC ya muerto!".

Teniendo en cuenta esto, por favor, avíseme si los puntos anteriores son realmente ciertos (como dije, los conozco a través de Google, discusión, etc.) o no. Y, ¿cuáles son los pros y los contras de Hibernate VS Java JDBC?

Answer 1

Aquí están las respuestas rápidas que sé

1) Puede conectarse a una base de datos existente. Pero sí, como se indica here

Si no tienes un modelo de objeto sólido, diría que Hibernate es una elección terrible.

2) Como se ha accedido a su base de datos desde diferentes aplicaciones para que pueda mantener bloqueos. Por otro lado, puedes truncar el almacenamiento en caché como se hace here .

3) Puede crear tablas manualmente y conectarlas usando el archivo .hbm.xml .

4) Puede utilizar cualquier tipo de consulta en hibernación como los simples criterios de consultas SQL.

5) Puede usar directamente el código SQL en Hibernate, si lo desea. Otra opción es usar criterios.

6) Hibernate NO es específico de DB. Puede ir a cualquier base de datos y conectarla con hibernación.

7) Usando bloqueos y dando derechos en la base de datos puede mantener la seguridad.

8) Acordó que las claves externas son desordenadas en Hibernate si no lo manejas bien . Así que usa el enfoque OO y mantén las cascadas bien, entonces Hibernate será una buena opción.

Answer 2

Hibernate es una gran herramienta y encontrarás un montón de documentations , books y artículos de blog al respecto.

Dirigiré todas sus preocupaciones:

Hibernate no se puede conectar con una base de datos "Existente". Siempre trata de crear uno propio.

Hibernate debe usar un procedimiento de administración de esquema de base de datos separado incluso para las pruebas de integración . Debería usar una herramienta incremental de control de versiones como FlywayDB para administrar sus cambios de esquema.

Nuestra base de datos puede acceder mediante la misma aplicación que se encuentra en diferentes plataformas (nube, servidor, VPS, computadora personal). Hibernate puede causar problemas debido a su almacenamiento en caché en esta situación.

No tiene que usar la memoria caché de segundo nivel, que usa implementaciones de caché de terceros. Todas las soluciones de almacenamiento en caché pueden romper la coherencia transaccional . La memoria caché de primer nivel garantiza lecturas repetibles a nivel de sesión y con el bloqueo optimista en su lugar puede evitar actualizaciones perdidas .

Nunca nos gusta dar el "código de creación de trabajo" al código java. Creamos tablas de forma manual, siempre.

La administración de la base de datos debe estar separada de su herramienta ORM. Esa es una mejor práctica de todos modos.

Podríamos tener que usar sentencias SQL muy largas y complejas. La última vez usamos una declaración con más de 150 líneas, uniendo más de 20 tablas. Dudamos si enfrentaremos problemas en esto cuando se trata de Hibernate.

Hibernate es ideal para operaciones de escritura y control de concurrencia. Aún necesita usar SQL nativo para consultas avanzadas (funciones de ventana, CTE). Pero Hibernate le permite ejecutar consultas nativas.

Nuestro código SQL es bueno y estándar. El código generado por Hibernate parece estar un poco sucio para nosotros.

No es necesario y, probablemente, tampoco debería utilizar la utilidad hbmdll.

Siempre usamos MySQL. Nunca use ninguna otra base de datos.

Eso es aún mejor. Por lo tanto, puede utilizar consultas nativas avanzadas sin tener en cuenta los problemas de portabilidad de la base de datos.

La aplicación que creamos requiere una seguridad máxima, relacionada con la medicina. Si se ha filtrado al menos un registro de datos, hemos terminado.

Hibernate no le impide proteger su base de datos o el código de acceso a datos. Todavía puede usar las medidas de seguridad de la base de datos con Hibernate también. Incluso puede usar Jasypt para habilitar todo tipo de funciones relacionadas con la seguridad:

• hashing avanzado de contraseñas
• encriptación bidireccional

Hay muchas claves externas, claves principales, claves compuestas, claves únicas, etc. en la base de datos. En foros, algunos se quejaron de que Hibernate se metió con ellos.

Todos ellos son compatibles con Hibernate. Además de las convenciones de JPA, Hibernate también ofrece un mapeo particular para cualquier mapeo exótico.

Decidimos probar hibernar porque algunas personas dicen: "¿Son ingenieros de software? ¡Usan JDBC ya muerto!".

Ese no es el argumento correcto para cambiar de una biblioteca que ya domina. Si cree que puede beneficiarse del uso de Hibernate, esa es la única razón de peso para cambiar de JDBC.

Answer 3

Respondiendo a los problemas mencionados anteriormente:

1. Hibernate no se puede conectar con una base de datos "Existente". Siempre trata de crear uno propio.

Esto está mal. Hibernate puede conectarse a una base de datos existente y no siempre intenta recrearlo. Solo debes cambiar el parámetro como hbm2ddl. auto hbm2ddl. auto .

2. Nuestra base de datos puede acceder mediante la misma aplicación que se encuentra en diferentes plataformas (nube, servidor, VPS, computadora personal). Hibernate puede causar problemas debido a su almacenamiento en caché en esta situación.

Hibernate tiene un caché ajustable, por lo que tampoco es un problema.

3. Nunca nos gusta dar la "tabla que crea el trabajo" al código java. Creamos tablas de forma manual, siempre.

No hay problema. Ver p.1 arriba. Además, hay varias bibliotecas convenientes para la creación y actualización indirecta de tablas (por ejemplo, liquibase ) que se pueden utilizar en pareja con hibernación perfectamente.

4. Podríamos tener que usar sentencias SQL muy largas y complejas. La última vez usamos una declaración con más de 150 líneas, uniendo más de 20 tablas. Dudamos si enfrentaremos problemas en esto cuando se trata de Hibernate.

Siempre puede usar llamadas JDBC directas e invocar consultas SQL nativas a través de hibernación, si es necesario.

5. Nuestro código SQL es bueno y estándar. El código generado por Hibernate parece estar un poco sucio para nosotros.

De nuevo, si tiene que invocar un código SQL complicado de lógica en lugar de generar automáticamente Hibernate, puede hacerlo.

6. Siempre usamos MySQL. Nunca use ninguna otra base de datos.

No es un problema en absoluto. Hibernate tiene soporte especial para el dialecto MySQL: org.hibernate.dialect.MySQLDialect .

7. La aplicación que creamos requiere máxima seguridad, relacionada con aspectos médicos. Si se ha filtrado al menos un registro de datos, hemos terminado.

Los problemas de seguridad no están relacionados con las técnicas de ORM. Hibernate es una capa orientada a objetos lógica y conveniente entre las llamadas JDBC de bases de datos puras y las herramientas de los programadores. No influye de alguna manera en la seguridad de red común.

Answer 4

Usar JDBC normal antiguo no significa que carezca de la industria de TI, sino que Hibernate también usa JDBC en la capa subyacente.

Qué ventajas nos da lo que debemos buscar.

1.) Mecanismo de Cache .

2.) Gestión de sessions , transactions , etc.

3.) Reducir esfuerzos en la escritura de consultas, más utilidades de hibernación como Query API , Criteria API , HQL

Las preguntas que ha planteado están más o menos cubiertas en los documentos de Hibernate .

También hay mucha más estrategia de almacenamiento en caché disponible ehcache, infinispan, depende del servidor que estamos implementando, JBOSS, Weblogic, Tomcat, etc. entorno ++ como la nube, caché distribuida, etc.

Hibernate aún le ofrece la opción de desactivar la creación automática de esquema y señalar el que cree usted.