Java - alternativas JDBC

Question

esto es solo una pregunta teórica.

Uso JDBC con mis aplicaciones Java para usar la base de datos (seleccionar, insertar, actualizar, eliminar o lo que sea). Realizo "manualmente" clases de Java que contendrán datos de las tablas de DB (atributo = columna de DB). Luego realizo consultas (ResultSet) y llenero esas clases con datos. No estoy seguro, si este es el camino correcto.

Pero he leído mucho sobre JDO y otras soluciones de persistencia.

¿Puede alguien recomendar las mejores alternativas usadas de JDBC, según su experiencia?

También me gustaría saber las ventajas de JDO sobre JDBC (en palabras simples).

He podido buscar en Google muchas de estas cosas, pero las opiniones de primera mano siempre son las mejores.

Gracias

Answer 1

La historia de persistencia de base de datos en Java ya es largo y lleno de giros y vueltas:

• JDBC es la API de bajo nivel que todo el mundo usa al final para hablar con una base de datos. Pero sin usar una API de nivel más alto, usted tiene que hacer todo el trabajo duro (escribir consultas SQL, mapear resultados a objetos, etc.).

• beans EJB 1.0 CMP Entity fue un primer intento de una API de alto nivel y ha sido adoptado con éxito por los grandes proveedores de Java EE (BEA, IBM), pero no por los usuarios. Los Beans de Entity eran demasiado complejos y tenían demasiada sobrecarga (entender, bajo rendimiento). ¡FALLO!

• EJB 2.0 CMP trató de reducir parte de la complejidad de beans de entidad con la introducción de las interfaces locales, pero la mayoría de la complejidad se mantuvo. EJB 2.0 también carecía de portabilidad (porque el mapeo relacional de objetos no formaba parte de la especificación y el descriptor de implementación era, por lo tanto, propietario). ¡FALLO!

• Entonces vino JDO cuales es un estándar independiente del almacén de datos para la persistencia de objetos (se puede utilizar con RDBMS, SGBDOO, XML, Excel, LDAP). Pero, aunque hay varias implementaciones de código abierto y aunque JDO ha sido adoptado por pequeños proveedores independientes (en su mayoría proveedores de OODBMS que esperan que los usuarios de JDO cambien más adelante de su almacén de datos RDBMS a un OODBMS, pero esto obviamente nunca sucedió), falló al ser adoptado por los grandes jugadores y usuarios de Java EE (debido a que tejer fue un dolor en el tiempo de desarrollo y asustar a algunos clientes, de una API de consulta extraña, de ser realmente demasiado abstracto). Entonces, aunque el estándar en sí mismo no está muerto, lo considero un fracaso. ¡FALLO!

• Y, en efecto, a pesar de la existencia de dos normas, APIs propietarias como Toplink, un reproductor de edad, o Hibernate han sido preferido por los usuarios a través de EJB CMP y JDO para el objeto persistente base de datos relacional (la competencia entre estándares, el posicionamiento poco claro de JDO, el fracaso anterior de CMP y el mal marketing tienen una parte de responsabilidad en esto, creo) e Hibernate en realidad se convirtió en el estándar de facto en este campo (es un gran marco de código abierto). ¡ÉXITO!

• Entonces Sun cuenta que tenían que simplificar las cosas (y más generalmente todo el Java EE) y lo hicieron en Java EE 5 con APP, la API de persistencia de Java, que es parte de EJB 3.0 y es la nuevo estándar para la persistencia de bases de datos relacionales de objetos. JPA unifica las API/productos EJB 2 CMP, JDO, Hibernate y TopLink y parece tener éxito donde EJB CMP y JDO fallaron (facilidad de uso y adopción). ¡ÉXITO!

En resumen, el estándar de Java para la persistencia base de datos es APP y debe ser preferido sobre otros APIs propietarias (mediante la implementación de JPA de Hibernate está bien pero el uso de la API JPA) a menos que un ORM no es lo que necesitar. Proporciona un API de nivel superior a JDBC y está destinado a ahorrarle mucho trabajo manual (esto se simplifica pero esa es la idea).

Answer 2

puedo recomendar Hibernate. Es ampliamente utilizado (y por buenas razones), y el hecho de que la especificación Java Persistence API haya sido dirigida por el diseñador principal de Hibernate garantiza que seguirá existiendo en el futuro inmediato :-) Si la portabilidad y la neutralidad del proveedor son importantes para usted, usted puede usarlo a través de JPA, por lo que en el futuro puede cambiar fácilmente a otra implementación de JPA.

A falta de experiencia personal con JDO, realmente no puedo comparar los dos. Sin embargo, los beneficios de Hibernate (o ORM en general) a primera vista parecen ser más o menos los mismos que figuran en el JDO page. Para mí los puntos más importantes son: la neutralidad

• DB: Hibernate soporta varios dialectos SQL en el fondo, el cambio entre DBS es tan fácil como cambiar una sola línea en la configuración de
• rendimiento: recuperación perezosa por defecto, y muchas más optimizaciones bajo el capó, que tendría que manejar manualmente con JDBC
• puede centrarse en su modelo de dominio y diseño OO en lugar de problemas DB de nivel inferior (pero, por supuesto, puede ajustar con precisión el DML y DDL si así lo desea)

Un posible inconveniente (de las herramientas ORM en general) es que no es adecuado para el procesamiento por lotes. Si necesita actualizar 1 millón de filas en su tabla, ORM de forma predeterminada nunca funcionará tan bien como una actualización por lotes JDBC o un procedimiento almacenado. Sin embargo, Hibernate puede incorporar procedimientos almacenados, y admite el procesamiento por lotes hasta cierto punto (todavía no estoy familiarizado con eso, así que no puedo decir si está a la altura en este aspecto en comparación con JDBC, pero a juzgar por lo que saber hasta ahora, probablemente sí). Entonces, si su aplicación requiere algún procesamiento por lotes, pero la mayoría trata con entidades individuales, Hibernate aún puede funcionar. Si está haciendo predominantemente procesamiento por lotes, tal vez JDBC es una mejor opción.

Answer 3

JDO construye tecnología JDBC. Del mismo modo, Hibernate todavía requiere JDBC también. JDBC es la especificación fundamental de Java sobre la conectividad de la base de datos.

Esto significa que JDBC le dará un mayor control pero requiere más código de plomería.

JDO proporciona una mayor abstracción y menos código de fontanería, porque se oculta gran parte de la complejidad.

Si está haciendo esta pregunta, supongo que no está familiarizado con JDBC. Creo que se necesita una comprensión básica de JDBC para poder utilizar JDO de forma efectiva, o Hibernate, o cualquier otra herramienta de abstracción superior. De lo contrario, es posible que encuentre un escenario en el que las herramientas ORM muestren un comportamiento que quizás no comprenda.

El tutorial de Java de Sun en su sitio web proporciona un material introductorio decente que lo guía por JDBC. http://java.sun.com/docs/books/tutorial/jdbc/.

Answer 4

Hibernate, seguramente. Es popular, incluso hay una versión .NET.

Además, hibernate se puede integrar fácilmente con Spring framework.

Y, se adaptará principalmente a las necesidades de cualquier desarrollador.

Answer 5

Una alternativa nueva y emocionante es GORM, que es la implementación de ORM de Grails. Ahora se puede usar solo. Debajo del capó usa Hibernate, pero le da una capa agradable encima con buscadores dinámicos geniales, etc.

Answer 6

Hibernate requiere que tenga un modelo de objetos para mapear su esquema. Si todavía piensas solo en términos de esquemas relacionales y SQL, quizás Hibernate no sea para ti.

Tiene que estar dispuesto a aceptar el SQL que Hibernate generará para usted. Si crees que puedes mejorar con SQL codificado a mano, quizás Hibernate no sea para ti.

Otra alternativa es iBatis. Si JDBC es SQL puro, e Hibernate es ORM, iBatis se puede considerar como algo entre los dos. Le da más control sobre el SQL que se ejecuta.

Answer 7

Todas estas capas de abstracción diferentes eventualmente usan JDBC. La idea es automatizar algunos de los trabajos tediosos y propensos a errores de la misma manera que los compiladores automatizan una gran parte del tedioso trabajo de escritura de programas (redimensionando una estructura de datos, no hay problema, solo recompile).

Tenga en cuenta, sin embargo, que para que funcionen hay suposiciones que deberá cumplir. Estos son usualmente razonables y bastante fáciles de usar, especialmente si comienza con el lado de Java en lugar de tener que trabajar con tablas de bases de datos existentes.

JDO es la convergencia de varios proyectos en un solo estándar Sun y el que yo sugeriría que aprendiera. Para la implementación, elija la que su IDE favorito sugiera en sus diferentes asistentes.

Answer 8

Recomiendo usar Hibernate, su forma realmente fantástica de conectarse a la base de datos, antes había pocos problemas, pero luego es más estable. Utiliza el mapeo basado en ORM, reduce el tiempo de redacción de las consultas hasta cierto punto y permite cambiar las bases de datos con un esfuerzo mínimo. Si necesita algún tutorial basado en video, por favor avíseme que puedo crearlo en mi servidor y enviarle el enlace.

Answer 9

Si desea escribir SQL usted mismo, y no desea un ORM, aún puede beneficiarse de algunos marcos que ocultan todo el tedioso manejo de la conexión (try-catch-finally). Eventualmente se olvidará de cerrar una conexión ...

Una de estas estructuras es bastante fácil de usar es Spring JdbcTemplate.

Answer 10

También hay par (http://db.apache.org/torque/) que personalmente prefiero porque es más simple, y hace exactamente lo que necesito.

Con torque puedo definir una base de datos con mysql (bien uso Postgresql, pero también se admite Mysql) y Torque puede consultar la base de datos y generar clases Java para cada tabla en la base de datos. Con Torque puede consultar la base de datos y recuperar objetos Java del tipo correcto.

Es compatible con las cláusulas where (Ya sea con un objeto Criteria o puede escribir el sql por su cuenta) y se une.

También admite claves foráneas, por lo que si tiene una tabla de usuario y una tabla de House, donde un usuario puede tener 0 o más casas, habrá un método getHouses() en el objeto de usuario que le proporcionará la lista of House se opone al usuario.

Para obtener un primer vistazo al tipo de código que puede escribir, consulte http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.html que contiene ejemplos que muestran cómo cargar/guardar/consultar datos con torsión. (Todas las clases utilizadas en este ejemplo se generan automáticamente en función de la definición de la base de datos).

Answer 11

Ebean ORM es otra alternativa http://ebean-orm.github.io/

Ebean utiliza anotaciones JPA para el Mapeo pero está diseñado para poder ser sin sesión. Esto significa que no tiene los conceptos adjuntos/desconectados y no persiste/fusiona/enjuaga - simplemente guarda() sus granos.

• yo esperaría Ebean a ser mucho más simple de usar que Hibernate, JPA o JDO

Así que si usted está buscando un enfoque alternativo potente para JDO o JPA se podía echar un vistazo a Ebean .

Answer 12

Eche un vistazo a MyBatis. A menudo se pasa por alto, pero es ideal para consultas complejas de solo lectura que usan características de propiedad de su DBMS.

http://www.mybatis.org

Answer 13

Aquí es cómo va con la persistencia de Java. Acabas de aprender Java, ahora quieres conservar algunos registros, puedes aprender JDBC. Te alegra que ahora puedas guardar tus datos en una base de datos. Luego decides escribir una aplicación un poco más grande. Te das cuenta de que se ha vuelto tedioso intentar, capturar, abrir una conexión, cerrar una conexión, transferir datos del conjunto de resultados a tu frijol ... Entonces, piensas que debe haber una manera más fácil. En java siempre hay una alternativa. Entonces haces un poco de google y en poco tiempo descubres ORM, y lo más probable es que hibernes. Estás tan emocionado que ahora no tienes que pensar en las conexiones. Tus tablas se crean automáticamente. Eres capaz de moverte muy rápido. Luego decides emprender un proyecto realmente grande, inicialmente te mueves muy rápido y tienes todas las operaciones crud en su lugar. Los requisitos siguen llegando, entonces un día estás arrinconado. Intentas guardar pero no está en cascada a los objetos hijos. Algunas cosas funcionaron como se explica en los libros que ha leído. No sabes qué hacer porque no escribiste las bibliotecas de hibernación. Desearías haber escrito el SQL tú mismo. Ahora es el momento de volver a pensar ... A medida que madure, se dará cuenta de que la mejor manera de interactuar con la Base de datos es a través de SQL. También te das cuenta de que algunas herramientas te ayudan a comenzar muy rápido, pero no pueden mantenerte activo por mucho tiempo. Esta es mi historia. Ahora soy un ibatis/usuario muy feliz.

Answer 14

Así es como funciona con la persistencia de Java. Acabas de aprender Java, ahora quieres conservar algunos registros, puedes aprender JDBC. Te alegra que ahora puedas guardar tus datos en una base de datos. Luego decides escribir una aplicación un poco más grande. Te das cuenta de que se ha vuelto tedioso intentar, capturar, abrir una conexión, cerrar una conexión, transferir datos del conjunto de resultados a tu frijol ... Entonces, piensas que debe haber una manera más fácil. En java siempre hay una alternativa.Entonces haces un poco de google y en poco tiempo descubres ORM, y lo más probable es que hibernes. Estás tan emocionado que ahora no tienes que pensar en las conexiones. Tus tablas se crean automáticamente. Eres capaz de moverte muy rápido. Luego decides emprender un proyecto realmente grande, inicialmente te mueves muy rápido y tienes todas las operaciones crud en su lugar.

Answer 15

JPA/Hibernate es una opción popular para ORM. Puede proporcionarle casi todas las características de ORM que necesita. La curva de aprendizaje puede ser pronunciada para aquellos con necesidades ORM básicas.

Hay muchas alternativas a JPA que proporcionan a ORM una menor complejidad para los desarrolladores con requisitos básicos de ORM. SourceForge consulta por ejemplo: http://sourceforge.net/directory/language:java/?q=ORM

soy parcial a mi solución, Sormula: sourceforge o bitbucket. Sormula fue diseñado para minimizar la complejidad a la vez que proporciona un ORM básico.

Answer 16

Use hibernate como un archivo JAR independiente y luego distribúyalo en sus diferentes aplicaciones web. Hasta aquí es la mejor solución que hay. Tienes que diseñar tus Clases, Interfaces, Enumeraciones para hacer un patrón DAO abstracto. Siempre y cuando tengas entidades y mapeos correctos. Solo necesitará trabajar con Objetos (Entidades) y no con HSQL.