Ediciones ENI Editorial | líder en informática
La persistencia de datos con JDBC y JPA
Introducción
El uso de datos en una aplicación web es inevitable y las bases de datos relacionales se utilizan de manera muy habitual. Como hay diferentes SGBDR (sistema de gestión de bases de datos relacionales) disponibles, Oracle (Sun en un inicio) ha descrito, a través de una especificación, cómo se debe comunicar una aplicación con una base de datos relacional. Se trata de JSR 221, que describe la tecnología JDBC (Java DataBase Connectivity) en su versión 4.2. La siguiente sección, La especificación JDBC, describe los elementos principales en el uso de esta tecnología.
Una gran parte del trabajo que va a realizar el desarrollador cuando usa una base de datos es hacer el enlace entre los objetos manipulados en el programa Java y los datos almacenados en las tablas. Como resultado, han nacido frameworks para simplificar esta tarea, basándose en la API JDBC. Estos frameworks se denominan ORM (Object Relational Mapping) porque su objetivo es mapear (Mapping) objetos (Object) y datos almacenados en una base de datos relacional. El framework más conocido es Hibernate. Ante la aparición de estos frameworks, Oracle decidió estandarizar el uso de ORM a través de la especificación JPA (Java Persistence API). En la actualidad, esta especificación ha sido renombrada como Jakarta Persistence API y está en su versión 3.0. Puede consultar...
La especificación JDBC
1. Descripción
La API JDBC forma parte de la plataforma Java SE. De hecho, el acceso a una base de datos no está reservado para las aplicaciones desplegadas en la plataforma Java EE.
La API JDBC permite escribir un programa Java independientemente del SGBDR subyacente. En la documentación oficial, se dice «Write Once, Run Anywhere». Esto significa que su programa se puede ejecutar con cualquier SGBDR sin cambiar una línea de código. Sin embargo, es necesario hacer una salvedad si desea utilizar funciones avanzadas de un SGBDR en particular.
La API JDBC se compone de interfaces y clases de herramientas. Por lo tanto, para poder comunicarse con una base de datos, es necesario tener una implementación de estas interfaces. Esta implementación la proporcionan librerías externas, denominadas controladores o drivers. Estos controladores generalmente están gestionados y controlados por las empresas que desarrollan los SGBDR.
2. Los diferentes tipos de controladores
Existen diferentes tipos de controladores JDBC. Hay cuatro de ellos:
-
Controladores de tipo 1 (controladores JDBC-ODBC): los controladores de tipo 1 son controladores que no se comunican directamente con SGBDR, sino que pasan a través de un controlador ODBC (Open DataBase Connectivity). Por lo tanto, actúan como una pasarela hacia la tecnología ODBC (JDBC-ODBC Bridge). La ventaja de este tipo de controlador es que se puede utilizar con diferentes SGBDR. Se debe instalar un controlador ODBC en la máquina cliente. Los límites se centran a nivel del rendimiento porque pasamos por una capa de software adicional. Las características disponibles también están limitadas por las características disponibles por el controlador ODBC. Este tipo de controlador solo se debe usar si no hay otro controlador disponible.
-
Controladores de tipo 2 (controladores nativos): los controladores de tipo 2 son controladores que no se comunican directamente con el SGBDR, sino que pasan a través de librerías nativas (específicas del SGBDR). Por lo tanto, el acceso es más eficiente que con un controlador de tipo 1. Por otro lado, en la máquina cliente es necesario instalar las librerías nativas relacionadas con el SGBDR o los SGBDR objetivos.
-
Controladores de tipo 3 (controladores de servidor intermedios Java puros):...
La especificación JPA
1. Descripción
La API JPA (Jakarta Persistence) forma parte de la plataforma Jakarta EE. Simplifica el acceso a los datos al proporcionar funciones avanzadas. La API JPA se basa en la API JDBC para comunicarse con las bases de datos. La API JPA se puede considerar como una supercapa de la API JDBC. Las principales características que ya se pueden mencionar son:
-
Automatización de la asociación (mapeo) entre los datos almacenados en las columnas de las tablas y las variables miembro de las clases Java.
-
El enfoque automático de las consultas SQL necesarias para manipular datos en el programa Java.
-
La estandarización de la arquitectura implementada para consultar una base de datos.
La especificación JPA es un ORM. Permite hacer más o menos transparente el puente entre el mundo de los objetos (escrito en Java) y el mundo relacional.
La versión actual de JPA 3.0 se describe en la especificación disponible en https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.pdf. El propósito del capítulo es presentar los elementos esenciales para iniciar un proyecto con JPA. Por lo tanto, no se abordarán los detalles de la versión 3.0.
2. Las principales implementaciones
JPA es «solo» una especificación. Para utilizar JPA en un proyecto, debe elegir una implementación de esta especificación. Hay varias y algunas son más populares que otras.
Estas son las principales implementaciones:
-
EclipseLink es la implementación de referencia desde JPA 2.0. La Fundación Eclipse es quien la mantiene. Para obtener más información, visite:http://www.eclipse.org/eclipselink/
-
Hibernate es el ORM más utilizado en el mundo Java. Se creó antes que la especificación JPA, pero la implementó tan pronto como apareció. Esta es la implementación utilizada para este capítulo. Red Hat (proveedor del servidor de aplicaciones JBoss, entre otros) mantiene esta implementación. Para obtener más información, visite http://hibernate.org/
-
OpenJPA es la implementación propuesta por la Fundación Apache. La última versión (3.1.2) ofrece una implementación de la versión JPA 2.2 (una versión de Java Persistence API y no de Jakarta Persistence). Para obtener más información...
Conclusión
Este capítulo ha permitido disponer de una visión general de las dos API que permiten acceder a los datos en una aplicación Java EE. La ampliación de conocimiento sobre la API JDBC es rápida. La implementación es sencilla y adaptada para proyectos pequeños. La API JPA requiere más tiempo y esfuerzo para adquirir competencias. La implementación es relativamente sencilla y adecuada, tanto para proyectos pequeños como grandes.