PDF de programación - Esquema de Persistencia en Lenguajes orientados a objetos

ESQUEMAS DE PERSISTENCIA EN LENGUAJES ORIENTADOS A OBJETOS

Martín Pablo Caballero

Tutores: Gabriel Bruno y Parruccia Luciano



Alumno becarío de investigación y servicio, de la carrera de Ingeniería en Sistemas de
Información, Facultad Regional Villa María de la Universidad Tecnológica Nacional.
Av. Universidad 450, Villa María, X5900GLB, Cba. [email protected]

Introducción

El objetivo de este proyecto es demostrar las diferentes alternativas a la hora
de elegir esquemas de persistencias para nuestros sistemas orientados a objetos. En
este estudio se tendrá en cuenta cómo interactúa desde un lenguaje orientado a
objetos con un modelo relacional o un repositorio de objetos de la manera más
transparente posible.

Metodología



Para este estudio se creará una aplicación orientada a objetos (Agenda), y que
la misma sea persistente, es decir que se puedan convertir en persistentes todos los
objetos que la aplicación necesite almacenar. Para ello se verán dos alternativas:

1.
2.

el mapeo de clases a través de Hibernate
el uso de un repositorio de objetos como DB4O (Database for

objects).

En cuanto a la programación se utilizarán dos lenguajes orientados a objetos:

Java y C#.NET.


Para realizar la persistencia de objetos a través de Hibernate se requiere
forzosamente el uso de una base de datos relacional. Por ende y, debido a la gran
variedad de SGBDR (Sistemas generadores de bases de datos relacionales), se hizo
un exhaustivo estudio entre las mismas para comparar rendimiento y funcionalidad.


Luego, se tomó el tiempo que llevó realizar la persistencia de los objetos con
este sistema y se comparó con el tiempo requerido usando DB4O. Se hizo una
inserción y recuperación masiva de objetos midiendo la eficiencia de cada sistema.


Para ambos casos no sólo se tomó en cuenta el rendimiento sino también en el
costo de desarrollo y sus respectivas funcionalidades. Se analizaron variables como la
dificultad en el uso, la automatización de tareas, la cantidad de código que se inserta
en el sistema en la capa de persistencia. Esto indica con qué facilidad se realiza la
materialización y desmaterialización de nuestros objetos al medio de persistencia.


Para todo esto se crearon cuatro aplicaciones: dos en Java y dos en C#.NET.

Tanto las de Java como las de C#.NET usaron ambos sistemas de persistencia.


La elección de estos dos lenguajes de desarrollo para llevar a cabo este trabajo
fue tomada para saber de qué manera éstos llevaban a cabo las distintas formas de
persistencia. Es decir cómo se utilizan Hibernate y DB4O en estos lenguajes que
consideramos, hoy por hoy, los dominantes del mundo de la programación.

Bases de datos relacionales utilizadas:
DB2
Postgres
SQLServer


Oracle
MySQL

El estudio realizado sobre éstas fue la realización de consultas de: inserción,
selección, actualización y eliminación de: 50.000, 500.000 y 1.000.000 de registros con
su correspondiente medición de tiempo.
Las herramientas pagas (DB2, SQLServer y Oracle) se han utilizado con versiones
gratuitas limitadas en funcionalidades (versiones express).


Tabla 1 - Medición de tiempo a las consultas realizadas a los motores de bases de datos

relacionales



Referencias de los gráficos

400000

300000

200000

100000

0

Insert

Gráfico 1 – comparación de tiempos
de consultas Insert entre las DBs
(Databases)

25000

20000

15000

10000

5000

0

Select

Gráfico 2 – comparación de tiempos
de consultas Select entre las DBs

12000

10000

8000

6000

4000

2000

0

20000

15000

10000

5000

0

Updat e

Delet e

Gráfico 3 – comparación de tiempos
de consultas Update entre las DBs

Gráfico 4 – comparación de tiempos
de consultas Delete entre las DBs

La base de datos relacional escogida para utilizar con Hibernate ha sido SQLServer
debido a sus buenos rendimientos con respecto a las demás y su fácil utilización (Ver
gráficos 1, 2, 3 y 4).

Para comprobar los tiempos se utilizó una agenda donde se persisten los contactos,
tareas y préstamos con sus respectivas asociaciones entre ellas y otras clases menos
importantes (ver gráfico 5).



Gráfico 5 – Diagrama de clases de una agenda simple utilizada para el estudio

0,000

20.000

5000,000

Hibernate
Db4ODB4O

20000,000

15000,000

10000,000

Gráfico 6 – Comparación de los tiempos de Hibernate y DB4O al
persistir 20.000 objetos.


Los resultados de comparar los tiempos entre Hibernate y DB4O han sido los
siguientes:



El resultado de persistir objetos es:

Gráfico 7 – Comparación de los tiempos de Hibernate y DB4O al
persistir 200.000 objetos.

Hibernate
Db4ODB4O

200.000

200000,000

150000,000

100000,000

50000,000

0,000


Con 20.000 objetos es 3,122754 veces más rápido DB4O (Ver gráfico 6).
Con 100.000 registros es 2,381433 veces más rápido DB4O (Ver gráfico 7).


DB40 [1]

Ventajas:

• Se apoyan en construcciones propias del lenguaje (ya sean de JAVA o .NET).
• Su aprendizaje es muy intuitivo y simple.
• Fácil de utilizar.
• No es necesario ningún tipo de mapeo para persistir los objetos.
• El modelo de entidades de nuestro sistema no necesita ser modificado ni tener
alguna estructura específica, lo cual nos da ciertas libertades y nos ayuda a

• Baja confiabilidad en el mercado informático.
• La falta de madurez pues es relativamente nuevo, más aún si se compara con
los ORMs que se apoyan en tecnologías de bases de datos relacionales que
disponen de una trayectoria muy importante.

• No son recomendables para grandes magnitudes de datos.
• Faltan herramientas confiables para trabajar con ellas.
• No es bueno a la hora de trabajar con varios lenguajes sobre el mismo

repositorio de objetos (no es muy transparente a la tecnología).

• Las modificaciones que hagamos en nuestro sistema (al modelo de entidades)
no serán trasladadas de una manera trivial sino con un esfuerzo considerable
(no es flexible a los cambios).

• Menor documentación debido a su bajo nivel de madurez en el mercado.
• No es muy utilizado aún.



HIBERNATE
En la implementación con Hibernate se utilizó el mecanismo de archivos de mapeo, en
contra de las anotaciones, para desacoplar el modelo de dominio de la capa de acceso
a datos [2].

Ventajas:

• Al estar apoyado sobre tecnologías de base de datos relacionales:

programación, pues se interactúa (de manera indirecta) con una DB.

o es muy fiable, dado que ha ido evolucionando con el correr de los años.
o Se puede utilizar la base de datos desde casi cualquier lenguaje de
o Ya no preocupa el hecho de interactuar directamente con la base de
datos ya que éste mecanismo es totalmente transparente y simula el
estar trabajando con un repositorio de objetos.

• Fácil de utilizar.
• Actualmente es uno de los más empleados en la industria.



Desventajas:

crear un sistema transparente a la tecnología de acceso a datos que
utilicemos.

• No es necesario el uso de otras tecnologías como en el caso de los ORMs
(Object-Relational Mapping) en los cuales necesitamos un motor de bases de
datos relacional (lo cual conlleva, algunas veces, a la adquisición de la licencia
correspondiente).


Desventajas:

• No se usan construcciones del lenguaje tales como:
o Predicate<T>, se reemplaza con el Criterion
o

IComparer<T>, se reemplaza de determinada manera con el uso de
Criterion

• El hecho de que en determinadas ocasiones no se usen construcciones
específicas del lenguaje, como en el caso del Criterion, dificulta la construcción
de una capa de acceso a datos que sea transparente a la tecnología
subyacente (en este caso un ORM).

• Uso obligatorio de un id para cada clase persistente.
• Los métodos de todas las clases persistentes deben ser virtuales.
• Necesidad de todos los métodos de seteo sin excepción para todos los

atributos de cada clase persistente.

• De esta forma, hay que tener en cuenta ciertas restricciones a la hora de crear
el modelo de entidades del negocio lo cual impide que este mecanismo sea
totalmente transparente a la tecnología de acceso a datos utilizada para la
persistencia (peor aún si elegimos las anotaciones como mecanismo de
mapeo).

• Se debe crear los archivos de mapeo de todas las clases persistentes, lo cual
conlleva a posibles errores e inconsistencias con respecto al modelo relacional
de la base de datos. Si bien hay herramientas disponibles para hacer este
trabajo de manera automática, esta es una cuestión adicional a considerar al
momento de crear el sistema.

• Al tener que utilizar una base de datos relacional, de acuerdo a la elegida, tal

vez resulte necesario adquirir su respectiva licencia.

• Se debe poner un constructor por defecto (sin argumentos), de manera

obligatoria.


Conclusión
Se recomienda el uso de Hibernate ya que, si bien se tienen que hacer ciertas
modificaciones en el modelo de entidades, su utilización en la industria es masiva y se
ve respaldada en la confiabilidad que brindan los motores de bases de datos
relacionales con décadas de desarrollo. Aunque se ha demostrado cierta superioridad
en cuestión de velocidad por parte de DB4O dicho beneficio no supera el hecho de
que todavía no es una herramienta madura en nuestro mercado laboral.

Agradecimientos:
Al
contribuyeron al desarrollo del mismo.

Referencias:
[1] http://www.db4o.com/ - página oficial del repositorio de objetos DB4O.
[2] http://www.hibe