Motores De Persistencia.

Como conclusión, aunque ésta pueda ser la opción preferible en un futuro, en el que las bases de datos orientadas a objetos alcancen una madurez y estandarización suficientes, en el presente resulta arriesgado aplicarla.

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.

ATRAS         SUMARIO         SIGUIENTE