|
5.
MOTORES DE PERSISTENCIA.
Hemos
visto que las opciones que se basan en imponer un único
modelo teórico (un único formato de datos)
a toda la aplicación padecen de graves inconvenientes.
En el caso de que toda la aplicación siga el modelo
relacional, perdemos las ventajas de la orientación
a objetos. En el caso de que toda la aplicación siga
el modelo orientado a objetos, tenemos que las bases de datos
que debemos usar están inmaduras y tienen un bajo
nivel de estandarización.
Examinemos
ahora la opción de que el programa sea
orientado a objetos y la base de datos sea relacional, lo
que, en principio, constituye la opción más
natural. Sin embargo, plantea el problema de cómo
hacemos que dos componentes con formatos de datos muy
diferentes puedan comunicarse y trabajar conjuntamente. Siguiendo
la metáfora anterior, se trata de hacer que dos personas
que hablan idiomas diferentes se comprendan.
La
solución es la misma que se daría en la
vida real. Se debe encontrar un traductor
que sepa traducir de cada idioma al otro. De esta forma,
las dos personas se entenderán sin necesidad de que
uno hable el idioma del otro. En el mundo de la programación
este traductor no es más que un componente de software
(concretamente, una capa de programación), al que
se le dan los nombres de “capa de persistencia”, “capa
de datos”, “correspondencia
O/R” (“OR mapping”) o “motor de persistencia”.
El
motor de persistencia traduce entre los dos formatos de
datos:
de registros a objetos y de objetos a registros.
La situación se ejemplifica en la figura 9. Cuando
el programa quiere grabar un objeto llama al motor de persistencia,
que traduce el objeto a registros y llama a la base de datos
para que guarde estos registros. De la misma manera, cuando
el programa quiere recuperar un objeto, la base de datos
recupera los registros correspondientes, los cuales son traducidos
en formato de objeto por el motor de persistencia.
Figura 9. Arquitectura de una aplicación con motor de persistencia
El
programa sólo ve que puede guardar objetos y recuperar
objetos, como si estuviera programado para una base de datos
orientada a objetos. La base de datos sólo ve que
guarda registros y recupera registros, como si el programa
estuviera dirigiéndose a ella de forma relacional.
Es decir, cada uno de los dos componentes trabaja
con el formato de datos (el “idioma”) que le
resulta más natural y es el motor de persistencia
el que actúa de traductor entre los dos modelos, permitiendo
que los dos componentes se comuniquen y trabajen conjuntamente.
Esta
solución goza de las mejores ventajas de los
dos modelos.
Por una parte, podemos programar con orientación
a objetos, aprovechando las ventajas de flexibilidad, mantenimiento
y reusabilidad. Por otra parte, podemos usar una base de datos
relacional, aprovechándonos de su madurez y su estandarización
así como de las herramientas relacionales que hay
para ella.
Se
calcula que un motor de persistencia puede reducir el código de una aplicación en un 40%, haciéndola
menos costosa de desarrollar. Además, el código
que se obtiene programando de esta manera es más limpio
y sencillo y, por lo tanto, más fácil de mantener
y más robusto. Por añadidura, el motor de persistencia
no sólo simplifica la programación, sino que
permite hacer ciertas optimizaciones de rendimiento que serían
difíciles de programar por nosotros mismos.
Como
conclusión, ésta es la mejor opción
en la actualidad para implementar una aplicación de
software.
|
