Comparación de las tecnologías de acceso a datos

Comprender la persistencia

La persistencia es un atributo de los datos que asegura que estarán disponibles incluso más allá de la vida de una aplicación. Para un lenguaje orientado a objetos como Java, la persistencia asegura que el estado de un objeto será accesible aunque la aplicación que creó el objeto haya dejado de ejecutarse. Hay diferentes maneras de lograr la persistencia. El enfoque tradicional al problema es utilizar sistemas de ficheros que almacenan la información necesaria en archivos planos. De esta manera, es difícil manejar grandes cantidades de datos ya que estos están distribuidos en diferentes archivos.

El mantenimiento de la consistencia de datos es también un problema con los sistemas de archivo plano, ya que la misma información puede ser replicada en varios archivos. La búsqueda de datos en archivos planos es lenta, sobre todo si los archivos están sin clasificar. Además, los sistemas de archivos proporcionan un apoyo limitado para el acceso concurrente, ya que no garantizan la integridad de los datos. Por todas estas razones, los sistemas de archivo no se consideran una buena solución de almacenamiento cuando se desea persistencia.

El enfoque más común hoy en día es utilizar bases de datos que sirven como depósitos de grandes cantidades de datos. Hay muchos tipos de bases de datos: relacional, jerárquica de la red, orientadas a objetos, y así sucesivamente. Estas bases de datos, junto con sus sistemas de gestión de bases de datos (DBMS), además de ofrecer un servicio de persistencia, también dan la posibilidad de gestionar la información que se conserva. Las bases de datos relacionales son el tipo utilizado en su mayoría. Una base de datos relacional es modelada como un conjunto de tablas relacionadas entre sí.

La llegada de las aplicaciones empresariales popularizó la arquitectura n-capas, que apunta a mejorar la mantenibilidad por la separación de la presentación, el negocio y el acceso a datos en los distintos niveles de la aplicación. La capa que separa la lógica de negocio y el acceso a datos es la capa de persistencia, lo que mantiene la aplicación independiente de la tecnología de base de datos subyacente. Con esta capa sólida en su lugar, el desarrollador ya no tiene que ocuparse de la persistencia de datos. La capa de persistencia encapsula el modo en que los datos se almacenan y se recuperan de una base de datos relacional.

Las aplicaciones Java han utilizado tradicionalmente el JDBC (Java Database Connectivity) de la API para persistir los datos en bases de datos relacionales. La API de JDBC utiliza SQL para realizar las operaciones de crear, leer, actualizar y eliminar datos. El código JDBC está incrustado en las clases de Java, en otras palabras, esta perfectamente acoplado a la lógica de negocio. Este código también se basa en gran medida en SQL, que no está estandarizado a través de bases de datos, que hace que la migración de una base de datos a otra sea difícil.

La tecnología de base de datos relacional hace hincapié en los datos y sus relaciones, mientras que el paradigma orientado a objetos utilizados en Java no se centra en los datos en sí, sino en las operaciones realizadas en esos datos. Por lo tanto, cuando estas dos tecnologías están obligadas a trabajar juntas, hay un conflicto de intereses. Además, los conceptos de programación orientada a objetos como la herencia, polimorfismo y asociación no se tratan en las bases de datos relacionales. Otro problema derivado del desequilibrio se produce cuando el usuario define los tipos de datos definidos en una aplicación Java que se asignan a bases de datos relacionales, ya que estos no proporcionan el soporte al tipo requerido.

Mapeo objeto-relacional

El mapeo objeto-relacional (ORM) ha surgido como una solución a, lo que se llama a veces, la diferencia de impedancia objeto-relacional. ORM es una técnica que persiste, de forma transparente, los objetos de la aplicación a las tablas de una base de datos relacional. Se comporta como una base de datos virtual, ocultando la arquitectura de base de datos subyacente del usuario. ORM proporciona una funcionalidad completa para llevar a cabo las operaciones de mantenimiento y consultas orientadas a objetos. El ORM también admite el mapeo de metadatos y ayuda en la gestión de transacciones de la aplicación.

Un ejemplo ayudará a ilustrar cómo funciona el ORM. Consideremos un objeto Coche que necesita persistir en la base de datos. El objeto Coche en el modelo de dominio es la representación de la tabla Coche en el modelo de datos. Los atributos del objeto Coche se derivan de las columnas de la tabla Coche. Existe una correspondencia directa entre la clase Coche y la tabla de Coche

Hay muchas herramientas de código abierto ORM, incluyendo Hibernate, iBATIS SQL Maps, y Java Persistence Ultra-Lite. La mayoría de estas herramientas son frameworks de persistencia que proporcionan una capa de abstracción entre la aplicación Java y la base de datos. Un framework de persistencia mapea los objetos, en el ámbito de la aplicación, a los datos que hay que persistir en una base de datos. Las asignaciones se pueden definir utilizando archivos XML o anotaciones de metadatos. El framework de persistencia está destinado a separar el código de la base de datos relacional y el código de la aplicación (es decir, la lógica de negocio), aumentando así la flexibilidad de aplicación. Un framework de persistencia simplifica el proceso de desarrollo al proporcionar una envoltura alrededor de la lógica de persistencia.

Comparación de las tecnologías de la persistencia

Cada uno de los frameworks tiene sus pros y sus contras. Vamos a considerar varios parámetros que ayudarán a decidir la mejor opción posible entre ellos para sus necesidades.

Simplicidad

En el desarrollo de muchas aplicaciones, el tiempo es un obstáculo importante, especialmente cuando los miembros del equipo deben ser entrenados para usar un framework particular. En tal escenario, iBATIS es la mejor opción. Es el más simple de los tres marcos, ya que sólo requiere conocimientos de SQL.

Solución completa ORM

Las soluciones tradicionales de ORM como Hibernate y JPA se deben utilizar para aprovechar el mapeo del objeto relacional. Hibernate y JPA mapean objetos Java directamente a las tablas de base de datos, mientras que iBATIS mapea objetos Java resultantes de las consultas SQL. En algunas aplicaciones, los objetos en el modelo de dominio son diseñados de acuerdo a la lógica de negocio y no pueden ser completados en el mapa por modelo de datos. En tal escenario, iBATIS es la elección correcta.

La dependencia de SQL

Siempre ha habido una separación entre las personas con altos conocimientos en Java y aquellos que se sienten cómodos con SQL. Para un programador con dominio de Java que quiere usar un framework de persistencia, sin mucha interacción con SQL, Hibernate es la mejor opción, ya que genera eficientemente las consultas SQL en tiempo de ejecución. Sin embargo, si desea tener un control completo sobre la consulta de base de datos utilizando procedimientos almacenados, iBATIS es la solución recomendada. JPA también es compatible con SQL a través del método createNativeQuery() de la EntityManager.

Soporte para los lenguajes de consulta

iBATIS soporta SQL, mientras que Hibernate y JPA utilizan sus propios lenguajes de consulta (HQL y JPQL, respectivamente), que son similares a SQL.

Rendimiento

Una aplicación debe funcionar bien para alcanzar el éxito. Hibernate mejora el rendimiento al proporcionar instalaciones de almacenamiento en caché que ayudan a una recuperación más rápida de los datos de la base de datos. iBATIS utiliza SQL que puede ser ajustado para un mejor rendimiento. El rendimiento de JPA depende de la aplicación de proveedor. La elección es particular a cada aplicación.

Portabilidad a través de diferentes bases de datos relacionales

A veces, tendrá que cambiar la base de datos relacional que utiliza su aplicación. Si utiliza Hibernate como su solución de persistencia, esta cuestión se resuelve fácilmente, ya que utiliza un dialecto de base de datos como propiedad en el archivo de configuración. Trasladar de una base de datos a otro es simplemente una cuestión de cambiar la propiedad dialecto en el valor apropiado. Hibernate usa esta propiedad como una guía para generar el código SQL que es específico de la base de datos dada.

Como se mencionó anteriormente, iBATIS requiere escribir su propio código del SQL, por lo tanto, la portabilidad de una solicitud de iBATIS depende de que SQL se ha implementado. Si las consultas se escriben utilizando SQL portátil, iBATIS también es portable a través de diferentes bases de datos relacionales. Por otra parte, la portabilidad de los JPA depende de la aplicación de proveedor que se esté utilizando. JPA es portable a través de diferentes implementaciones, como Hibernate y TopLink.

Comunidad de soporte y documentación

Hibernate es un ganador claro en este aspecto. Hay muchos foros centrados en Hibernate donde los miembros responden activamente a las consultas. IBATIS y JPA están alcanzando, poco a poco, este aspecto.

La portabilidad entre plataformas no-Java

iBATIS soporta .Net y Ruby on Rails. Hibernate proporciona una solución de persistencia para .NET en la forma de NHibernate. De la JPA, al ser una API de Java específica, obviamente no es compatible con la plataforma que no sea Java. Esta comparación se resume en la Tabla:

Conclusión

iBATIS, Hibernate y JPA son tres mecanismos diferentes de persistencia de datos en una base de datos relacional. Cada uno tiene sus propias ventajas y limitaciones. iBATIS no proporciona una solución ORM completa, y no proporciona ninguna asignación directa de los objetos y modelos relacionales. Sin embargo, iBATIS le proporciona un control completo sobre las consultas. Hibernate proporciona una solución ORM completa, pero no le ofrece control sobre las consultas. Hibernate es muy popular y tiene una amplia comunidad activa que proporciona soporte para los nuevos usuarios. JPA también ofrece una solución completa ORM, y proporciona soporte para programación orientada a objetos con características como la herencia y el polimorfismo, pero su rendimiento depende del proveedor de persistencia.

La elección de un mecanismo de persistencia en particular es una cuestión a sopesar con todas las características que se describen en la sección de la comparación. Para la mayoría de los desarrolladores, la decisión estará en función de si usted requiere un control completo sobre SQL para su aplicación, necesidad de auto-generar SQL o, simplemente, quiere una solución fácil y completa de programa de ORM.