Las aplicaciones empresariales a menudo se ocupan de operaciones como la recopilación, el procesamiento, la transformación y la generación de informes de una gran cantidad de datos. Estos datos generalmente se almacenan en un servidor de base de datos en una ubicación particular y se recuperan a pedido. La aplicación se encarga de procesar los datos de la base de datos y finalmente presentarlos para el consumo del cliente. Pero las complejidades involucradas en mitigar el intercambio de datos entre diferentes arquitecturas es el verdadero desafío al que se enfrentan los desarrolladores. El corazón del problema radica en facilitar la complicada relación del movimiento de datos entre el código utilizado para desarrollar la aplicación y el modelo de almacenamiento utilizado para la persistencia de datos. En resumen, la idea es crear un mecanismo para una interacción perfecta entre dos modelos inflexibles:la naturaleza orientada a objetos del lenguaje Java y el modelo de base de datos relacional.
API básicas para bases de datos
La plataforma Java ya tiene API estándar para trabajar con sistemas de bases de datos en forma de API JDBC. Estas API son excelentes para trabajar con la base de datos y brindan los medios necesarios para interactuar con la base de datos de manera conveniente desde el lenguaje Java. Pero el problema es que Java es un lenguaje orientado a objetos. El JDBC proporciona API centrales para la interacción con la base de datos y no se centra en transformar la estructura de filas y columnas de la tabla de la base de datos en una clase de entidad. Por tanto, se busca una capa de API que funcione por encima de la API de JDBC. La API de persistencia, o JPA, mitiga dos modelos arquitectónicamente diferentes con el objetivo de aprovechar la fluidez de la operación. La API ayuda a representar una tabla de relaciones de base de datos como POJO y puede tratarse de manera similar a través del código Java. La API central de JDBC funciona en segundo plano para lidiar con las complejidades de la comunicación y la conexión de la base de datos, mientras que JPA permite que las transacciones se realicen de acuerdo con el código orientado a objetos del lenguaje Java. Sin embargo, el mapeo de datos entre la base de datos relacional y Java no es una tarea fácil.
Soporte de persistencia de Java
En una base de datos relacional típica, la información se almacena en una estructura de filas y columnas. El intercambio de datos entre un sistema de base de datos y el modelo de objetos de la aplicación Java es difícil porque Java designa una única entidad como clase denotada por un conjunto de propiedades y operaciones aplicadas sobre ellas. Por lo tanto, para conformar un desajuste de comportamiento entre las dos arquitecturas diferentes, un programador de Java tiene que escribir muchas líneas de código. Estas líneas de código ayudan a transformar los datos de fila y columna de la tabla de la base de datos en objetos Java. Pero, a menudo, estas líneas de código se vuelven demasiado repetitivas, lo que da como resultado que el código fuente esté repleto de códigos repetitivos. Esto no es deseable y viola el principio básico de reutilización orientado a objetos. Aunque los códigos inteligentes pueden mitigar muchas de las adversidades, no es una solución fácil. La aparición de soluciones de terceros es un respiro en el mapeo de datos de bases de datos en objetos Java, pero no eran estándar. La implementación de cada proveedor varió considerablemente de otro. Todo esto significa que la situación exigía una biblioteca API de persistencia estándar de la propia plataforma Java. Esto condujo a la introducción de la API de persistencia de Java (JPA), especialmente para cerrar la brecha entre el modelo de dominio orientado a objetos de Java y el sistema de base de datos.
Soluciones patentadas
Comprenda que las soluciones relacionales de objetos existen desde hace bastante tiempo, incluso antes del nacimiento del propio lenguaje Java. Por ejemplo, el producto TopLink de Oracle en realidad comenzó con Smalltalk y luego cambió a Java. Hoy en día, es parte de los servidores OracleAS, WebLogic y OC4J. De hecho, las dos API de persistencia más populares solían ser TopLink de Oracle, un estándar patentado en el dominio comercial, e Hibernate en el dominio de la comunidad de código abierto. Más tarde, Hibernate se hizo más popular e influyó mucho en la creación de la biblioteca JPA estándar.
Asignadores de datos
Un mapeador de datos es básicamente un patrón arquitectónico propuesto por Martin Fowler en su libro Patterns of Enterprise Application Architecture. , 2003. Proporciona una forma parcial de abordar el problema relacional de objetos. El mapeador ayuda a crear una estrategia que cae en la categoría entre JDBC simple y una solución de mapeo relacional de objetos completamente funcional. Aquí, los desarrolladores de aplicaciones crean una cadena SQL sin procesar para asignar tablas de bases de datos a objetos Java utilizando el método de asignación de datos. Existe un marco popular que utiliza esta técnica de mapeo entre la base de datos SQL y el objeto Java, llamado Apache iBatis. El proyecto Apache iBatis ha sido declarado inactivo ahora. Sin embargo, los creadores originales de Apache iBatis han transferido el proyecto a MyBatis y está en desarrollo activo.
A diferencia de otras soluciones de problemas relacionales de objetos que utilizan el marco de mapeadores de datos como MyBatis, podemos tener un control completo sobre las transacciones SQL con la base de datos. Es una solución liviana y no tiene la sobrecarga de un marco ORM completo. Pero, hay un problema con los mapeadores de datos. Cualquier cambio realizado en el modelo de objetos tiene repercusiones en el modelo de datos. Uno tiene que hacer cambios significativos a las sentencias SQL directamente como consecuencia. La naturaleza minimalista del marco ayuda a los desarrolladores a incorporar nuevos cambios y modificaciones según la necesidad. Los mapeadores de datos son particularmente útiles en una situación en la que necesitamos un marco mínimo, manejo explícito de SQL y más control para la modificación del desarrollador.
JDBC
JDBC (Java Database Connectivity) es una versión específica de Java de la especificación ODBC (Object Database Connectivity) de Microsoft. El ODBC es un estándar para conectar cualquier base de datos relacional desde cualquier lenguaje o plataforma. JDBC proporciona una abstracción similar con respecto al lenguaje Java. JDBC usa SQL para interactuar con la base de datos. Los desarrolladores deben escribir consultas DDL o DML según la especificación sintáctica de la base de datos backend, pero procesarlas utilizando el modelo de programación Java. Existe un estrecho acoplamiento entre la fuente de Java y las sentencias de SQL. Podemos recurrir a declaraciones SQL sin formato y manipularlas estáticamente según las necesidades. Debido a su naturaleza estática, es difícil incorporar cambios. Además, los dialectos de SQL varían de un proveedor de base de datos a otro. JDBC está conectado a la base de datos y no al modelo de objetos del lenguaje Java. Por lo tanto, pronto se siente engorroso trabajar con él, especialmente cuando aumenta la interacción con la base de datos del código fuente de Java. Sin embargo, JDBC es el soporte principal para la persistencia de bases de datos en Java y forma la base para marcos de trabajo de alto nivel.
EJB
Enterprise Java Bean (EJB) con J2EE trajo algunos cambios nuevos en el campo de la persistencia de Java en forma de entidad bean. La idea era aislar a los desarrolladores de la intervención directa en las complejidades de la persistencia de la base de datos. Introdujo un enfoque basado en la interfaz. Hay un compilador de beans especializado para generar la implementación para la persistencia, la gestión de transacciones y la delegación de lógica empresarial. Se utilizaron descriptores de implementación XML especializados para configurar los beans de entidad. El problema es que EJB, en lugar de simplificar las cosas, incorporó mucha complejidad. Como resultado, a pesar de las numerosas mejoras posteriores, como la introducción de Enterprise JavaBeans Query Language (EJB QL), pronto perdió popularidad.
Objeto de datos Java
El JDO (Java Data Object) trató de abordar el problema que enfrentaba el modelo de persistencia EJB. Proporciona una API para una persistencia transparente y está diseñado para funcionar con EJB y J2EE. JDO es un producto fuertemente influenciado y soportado por bases de datos orientadas a objetos. Los objetos de persistencia son objetos simples de Java que no requieren que un desarrollador implemente ninguna clase o interfaz especial. Las especificaciones de persistencia de objetos normalmente se definen en un metarchivo XML. Los lenguajes de consulta admitidos están orientados a objetos por naturaleza. A pesar de muchas buenas características, la especificación JDO no logró mucha aceptación entre la comunidad de desarrolladores.
API de persistencia de Java
Hubo una serie de marcos de persistencia patentados tanto en el dominio comercial como en el dominio de código abierto. Frameworks como Hibernate y TopLink parecían satisfacer bastante bien la necesidad de la aplicación. Como resultado, se eligió Hibernate como base principal para crear un modelo de persistencia estándar llamado JPA.
JPA es un marco de persistencia de Java liviano estándar que ayuda a crear un mapeo relacional de objetos usando POJO. JPA también ayuda a integrar la persistencia en una aplicación empresarial escalable. Es fácil de usar porque solo hay una pequeña cantidad de clases que deben exponerse a una aplicación interesada en usar el modelo de persistencia JPA. El uso de un POJO es quizás el aspecto más intrigante de JPA. Significa que no hay nada especial en el objeto; eso lo hace persistente. El mapeo relacional de objetos está dirigido por metadatos. Se puede hacer mediante el uso de anotaciones internamente dentro del código o externamente. usando XML.
Las API persistentes de JPA existen como una capa separada del objeto persistente. La lógica comercial generalmente invoca la API y pasa el objeto persistente para operar sobre ellos. Aunque la aplicación reconoce la API persistente, el objeto persistente, al ser POJO, desconoce por completo su capacidad de persistencia.
Conclusión
Este artículo proporcionó una descripción general de algunas de las soluciones propietarias disponibles antes de la introducción de JPA, como el mapeador de datos, JDBC y EJB. La idea es dar una idea de lo que condujo a la creación de JPA y un poco sobre la técnica persistente de su predecesor. Manténganse al tanto; los artículos posteriores profundizan en aspectos más específicos de la API de JPA.
