example - jdbc java descargar

Java-alternativas JDBC (16)

esta 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 clases Java "manuales" que contendrán datos de tablas DB (atributo = columna 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 de JDBC usadas, en función de su experiencia?

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

Pude googlear muchas de estas cosas, pero las opiniones de primera mano siempre son las mejores.

Gracias

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. 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.

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

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

Esperaría que Ebean fuera mucho más simple de usar que Hibernate, JPA o JDO

Entonces, si estás buscando un enfoque alternativo potente para JDO o JPA, puedes echarle un vistazo a Ebean.

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

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.

Debe 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.

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

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

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

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 mucha de la complejidad está oculta.

Si hace 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 guiará a través de JDBC. http://java.sun.com/docs/books/tutorial/jdbc/ .

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 ORM con menos complejidad para desarrolladores con requisitos básicos de ORM. Consulta sourceforge 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.

La historia de la persistencia de la base de datos en Java ya es larga y está llena 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.).
EJB 1.0 CMP Entity Beans fue un primer intento para una API de nivel superior 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). ¡FALLAR!
EJB 2.0 CMP intentó reducir parte de la complejidad de Entity Beans con la introducción de interfaces locales, pero la mayoría de la complejidad permaneció. 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). ¡FALLAR!
Luego vino JDO, que es un estándar independiente del almacén de datos para la persistencia de objetos (se puede usar con RDBMS, OODBMS, 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. ¡FALLAR!
Y, de hecho, a pesar de la existencia de dos estándares, APIs propietarias como Toplink , un antiguo reproductor o Hibernate han sido preferidas por los usuarios sobre EJB CMP y JDO para la persistencia de bases de datos relacionales (competencia entre estándares, posicionamiento poco claro de JDO, falla 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 se dio cuenta de que tenían que simplificar las cosas (y más generalmente toda la EE de Java) y lo hicieron en Java EE 5 con JPA , la API Java Persistence, que es parte de EJB 3.0 y es el nuevo estándar para 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 de la base de datos es JPA y debe preferirse a otras API propietarias (utilizar la implementación de JPA de Hibernate es correcto, pero usar la API JPA) a menos que un ORM no sea lo que necesita. Proporciona un API de nivel superior a JDBC y está destinado a ahorrarle mucho trabajo manual (esto se simplifica pero esa es la idea).

Puedo recomendar Hibernate . Es ampliamente utilizado (y por buenas razones), y el hecho de que la especificación de la API Java Persistence fue liderada 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 , puede usarlo a través de JPA, por lo que en el futuro puede cambiar fácilmente a otra implementación de JPA.

Al carecer 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 la página de JDO . Para mí, los puntos más importantes son:

Neutralidad DB: Hibernate admite varios dialectos SQL en segundo plano, cambiar entre DB es tan fácil como cambiar una sola línea en su configuración
rendimiento: recuperación diferida 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 puede, por supuesto, ajustar con precisión el DML y el 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.

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 el mínimo esfuerzo. Si necesita algún tutorial basado en video, avíseme si puedo crearlo en mi servidor y enviarle el enlace.

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). Finalmente, se olvidará de cerrar una conexión ...

Uno de esos marcos que es bastante fácil de usar es Spring JdbcTemplate .

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

Con el torque, puedo definir una base de datos con mysql (bueno, yo uso Postgresql, pero Mysql también es compatible) y Torque puede consultar la base de datos y luego 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 cláusulas where (ya sea con un objeto Criteria o puede escribir el sql por su cuenta) y se une.

También es compatible con claves externas, por lo que si tiene una tabla de usuario y una tabla de casa, 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 de objetos de la casa. usuario propio.

Para conocer por primera vez el 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 torque. (Todas las clases utilizadas en este ejemplo se generan automáticamente en función de la definición de la base de datos).

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).

Sin embargo, tenga en cuenta 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 de Sun y el que le sugiero que aprenda. Para la implementación, elija la que su IDE favorito sugiera en sus diferentes asistentes.

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

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. Debes 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.