![El resultado de la consulta es un objeto POJO "book" que contendría los siguientes datos:
BOOK[
12345
Las reglas no escritas para triunfar en la empresa
Informática profesional
PUBLISHER[002 - STARBOOK - C Servidores, Valencia]
2011-12-18
40
CHAPTER[1 - Cap1 - 100]]
Del mismo modo, persistir Objetos POJO mediante JDBC, pero para que os hagáis una idea,
tendríamos que crear una transacción, y dentro de esta recorrer las propiedades del objeto Book,
para completar la sentencia INSERT, pero a su vez cuando una propiedad del objeto Book fuese un
listado habría que repetir el proceso con bucles sobre las tablas/entidades correspondientes.
Conclusión
Utilizar JDBC implica construir y ejecutar repetidamente sentencias SELECT, INSERT, UPDATE y
DELETE.](https://image.slidesharecdn.com/bbddenjava-150705114243-lva1-app6891/85/Bbdd-en-java-7-320.jpg)
Bbdd en java
- 1. Tutorial básico de bases de datos en Java mediante JDBC. Previo y recomendado http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina= Este tutorial continua a Introducción a bases de datos SQL. Se recomienda leer posteriormente Buscar tutoriales de Hibernate. Otra alternativa recomendada es Introducción a bases de datos NoSQL. Driver JDBC - Accediendo a la base de datos mediante Java Database Connectivity Cada propietario de base de datos implementa un driver JDBC que podemos utilizar en nuestras aplicaciones java. Normalmente habrá un driver por versión y tipo de base de datos, puesto que no siempre se cumple la compatibilidad hacia versiones anteriores. El driver JDBC es el más básico de que dispone Java para acceder a la base de datos, por lo tanto utilizarlo implica: · Manejar manualmente las conexiones, nos estamos arriesgando a no cerrar correctamente las conexiones a la base de datos, y un sin fin de problemas derivados. Nota: En el caso de aplicaciones web, el servidor de aplicaciones puede que implemente un pool de conexiones automático. Por ejemplo en el caso de Apache Tomcat 6, colocando el driver JDBC en el directorio lib del propio Tomcat, no en nuestra aplicación, y configurando el fichero de contexto (context.xml) de nuestra aplicación (o también directamente la configuración global del servidor Tomcat - server.xml) podremos utilizar su pool de conexiones por defecto. · Cada vez que escribamos una query SQL vamos a tener que escribirla completamente, puesto que cualquier sentencia Insert, Update o Select requerirá escribir un gran número de campos. · Manejar manualmente las relaciones, teniendo en cuenta el orden de inserción o modificación de tablas y columnas. Esto puede no parecer un gran problema, pero se complica exponencialmente en modelos de datos complejos. · El SQL lo escribiremos para la versión y tipo de nuestra base de datos, por lo tanto, este código estará completamente acoplado, sin poder ser utilizado sin ser rehecho con otra base de datos. Realicemos operaciones CRUD (Create, Read, Update, y Delete) simples con JDBC Una simple conexión a la base de datos
- 2. El resultado de su ejecución Un simple consulta El resultado de su ejecución
- 3. Una simple actualización de un registro El resultado de su ejecución Una simple inserción/persistencia de un registro El resultado de su ejecución Un simple borrado El resultado de su ejecución
- 4. POJO's (Plain Old Java Objects) mediante JDBC Para crear el modelo de objetos de dominio utilizamos JavaBeans, que son en realidad Plain Old Java Objects (POJO's), los cuales son clases que deben tener un constructor sin ningún tipo de argumento, y normalmente métodos públicos Getters y Setters para mapear todos sus atributos privados. Se diferencias de los EJB's porque no implementan interfaces (en el caso de los EJB's javax.ejb). Veamos dos ejemplos.
- 5. Utilizamos una clave ajena para referenciar PUBLISHER con la tabla BOOK, y además hay una relación many-to-one entre CHAPTERS y BOOKS. Para modelar esto en los POJO's definimos listas de atributos, en vez de un simple atributo. Fíjate en el ejemplo del POJO de Book, que tiene una lista para los chapters. Para manejar esta incompatibilidad entre modelo-relacional y objetos necesitamos un proceso que convierta de modelo relacional a objetos POJO's cuando recibimos la información. Al código que realiza esta conversión por nosotros lo llamamos ORM (Object/Relational Mapping). ¿Entonces ya puedo hacerlo todo? Como podemos deducir, a estas alturas del tutorial, es evidente que hay diferencias entre el modelo de objetos y el modelo relacional. El modelo de objetos está basado en el análisis del negocio, y en consecuencia define el modelo del dominio. El modelo relacional está basado en cómo está organizada la información, en columnas y filas. Los frameworks ORM, como por ejemplo Hibernate, nos dan estrategias para abstraernos de las asociaciones, herencia y polimorfismos que no casan entre los modelos de objetos y relacionales. ORM manual Imaginemos que queremos mostrar los datos de las siguientes tablas de nuestro ejemplo si nun ORM, directamente con JDBC: Cada una con sus correspondientes registros: Tabla Books
- 6. Tabla Publisher Tabla Chapters El método que tendríamos que crear sería tremendamente largo:
- 7. El resultado de la consulta es un objeto POJO "book" que contendría los siguientes datos: BOOK[ 12345 Las reglas no escritas para triunfar en la empresa Informática profesional PUBLISHER[002 - STARBOOK - C Servidores, Valencia] 2011-12-18 40 CHAPTER[1 - Cap1 - 100]] Del mismo modo, persistir Objetos POJO mediante JDBC, pero para que os hagáis una idea, tendríamos que crear una transacción, y dentro de esta recorrer las propiedades del objeto Book, para completar la sentencia INSERT, pero a su vez cuando una propiedad del objeto Book fuese un listado habría que repetir el proceso con bucles sobre las tablas/entidades correspondientes. Conclusión Utilizar JDBC implica construir y ejecutar repetidamente sentencias SELECT, INSERT, UPDATE y DELETE.
- 8. Por lo tanto: Creamos mucho código que además estará muy acoplado a la base de datos que estemos usando. Tenemos que iterar manualmente sobre las propiedades de objetos como ResultSet cada vez que consultemos algo en la base de datos. A su vez es muy costoso crear PreparedStatements en cada caso por el mismo motivo de las iteraciones, pero en este caso sería sobre los POJO's para Inserts, Updates y Deletes. Tendríamos que gestionar manualmente el orden de las inserciones, actualizaciones y borrados para que no hubiese problemas con la integridad referencial.