Soluciones para la Persistencia de Clases sin Bases de Datos Orientadas a Objetos: Estrategias y Casos de Uso

Soluciones para la Persistencia de Clases sin Bases de Datos Orientadas a Objetos

Existen dos posibilidades principales para resolver el problema de la persistencia de clases en almacenamiento persistente cuando no se dispone de bases de datos orientadas a objetos (OO). A continuación, se describen ambos enfoques, junto con sus ventajas y desventajas.

Superobjeto Persistente

Este enfoque implica la creación de una clase denominada SuperObjetoPersistente. Esta clase define los métodos esenciales para la persistencia:

• Materializar: Convierte una tabla de la base de datos en un objeto, dotándolo de comportamiento.
• Desmaterializar: Realiza la operación inversa a la materialización, eliminando el comportamiento de los objetos para convertirlos en tablas.

Las clases que requieren persistencia heredan de la clase SuperObjetoPersistente.

Ventajas del Superobjeto Persistente

• Implementación rápida.
• Simplicidad conceptual.
• Potencialmente mejor rendimiento.

Desventajas del Superobjeto Persistente

• Responsabilidades complejas y no relacionadas: Los métodos de materialización y desmaterialización no son responsabilidades inherentes a la clase que necesita persistencia.
• Limitaciones con la herencia: Si el lenguaje de programación no admite herencia múltiple, las clases que necesitan persistencia no pueden heredar de otras clases.
• Alternativa con interfaces: En ausencia de herencia múltiple, se puede utilizar una relación de realización, donde SuperObjetoPersistente se convierte en una interfaz.
• Acoplamiento: Se introduce acoplamiento entre la capa lógica y la capa de administración de datos.

Esquema de Persistencia

Este enfoque introduce una capa de persistencia entre la capa lógica de negocio y la capa de administración de datos. Se crean clases intermediarias, denominadas clases de persistencia, que actúan como puente entre los gestores de la aplicación y las entidades con la base de datos. Cada clase de persistencia se encarga de materializar y desmaterializar los objetos de una clase específica que necesita persistencia.

Ventajas del Esquema de Persistencia

• Mejora la cohesión: Evita que las clases de negocio tengan la responsabilidad de la persistencia.
• Principio de inversión de control:
  • El gestor solicita a la capa de persistencia una operación para una clase específica.
  • La capa de persistencia busca el objeto.
  • La capa de persistencia guarda el objeto en la capa de administración de datos.
  • El gestor solicita a la capa de persistencia una operación para una clase específica.
  • La capa de persistencia busca el estado del objeto en la base de datos.
  • La capa de persistencia devuelve el objeto a la capa lógica de negocio.

Desventajas del Esquema de Persistencia

• Mayor complejidad en la implementación.
• Posible impacto en el rendimiento debido a la mayor cantidad de clases involucradas.

Estrategias para la Administración de Sistemas Heredados en la Evolución del Software

Durante el proceso de evolución del software, es común encontrarse con la necesidad de administrar sistemas heredados. Existen cuatro estrategias principales para abordar esta situación:

1. Desechar el Sistema Completamente

   Esta opción es adecuada cuando el sistema ya no aporta valor a los procesos empresariales. Suele ocurrir cuando los procesos han cambiado significativamente desde la implementación del sistema y ya no dependen de él.

2. Mantener el Sistema sin Cambios

   Se elige esta opción cuando el sistema sigue siendo necesario, es estable y los usuarios realizan pocas solicitudes de cambio.

3. Reemplazar Total o Parcialmente el Sistema

   Esta estrategia se aplica cuando factores como la obsolescencia del hardware impiden que el sistema siga operando, o cuando existen sistemas comerciales que permiten un desarrollo más económico. A menudo se adopta un enfoque de reemplazo evolutivo, sustituyendo componentes grandes por sistemas comerciales y reutilizando otros componentes cuando es posible.

4. Someter el Sistema a Reingeniería

   Esta opción es viable cuando la calidad del sistema se ha degradado debido a cambios continuos, pero aún se requieren modificaciones. El proceso puede incluir el desarrollo de nuevas interfaces para que el sistema original pueda interactuar con sistemas más modernos.