Introducción a los componentes de persistencia

Los componentes de persistencia brindan tres servicios a la aplicación:

• Cargar un conjunto de datos relacionados
• Mantener en memoria los cambios realizados por el usuario a estos datos
• Finalmente sincronizarlos con el medio de persistencia cuando sea solicitado.

Estos servicios ayudan al controlador de interface a garantizar del Marco Transaccional de una operación.

Beneficios

Cuando los datos a manejar son simples, es fácil mantener entre pedidos de página la información en la sesión en forma plana, en toba esto lo hace generalmente el CI. Cuando los datos empiezan a ser complejos, fruto del manejo de relaciones en la base de datos, es difícil que mantener estas estructuras en forma manual.

La solución a este problema es describir en forma de componentes a las tablas y relaciones que se van a manipular en la transacción.

La solución que brindan estos componentes son:

• Guardar el estado de los datos que se manejan en la operación. El ci sólo tendrá que guardar en sesión información relacionada con la presentación pero ya no más los datos de la operación.
• Brindar una API de manipulación de datos orientada a datos tabulares.
• Brindar un mecanismo de carga y sincronización. Para mantener independencia con el medio, este proceso es guiado por una clase separada llamada Administrador de persistencia, es la que en definitiva forma las query de carga y los comandos update, insert y delete para el caso de una base de datos relacional.

Comportamiento General

Durante la definición

• Se modelan datos tabulares, generalmente tablas de una base relacional. El componente utilizado es el datos_tabla.

• Se modelan las relaciones entre estas tabla (utilizando el componente datos_relacion).

• Se asigna la relación al CI encargado de la transacción.

Durante la ejecución

Siempre desde el CI encargado de la transacción:

• Se cargan datos en la relación con una restricción (generalmente la clave de la tabla principal que se está editando), en caso del alta de un nuevo registro se resetea la relación (por si estaba cargada con algún dato previamente).

      <?php
          function evt__cuadro_personas__seleccion($id)
          {
              $this->dep('datos')->cargar($id);
              $this->set_pantalla('edicion');
          }
      ?>
  

• Los eventos de los distintos elementos de interface (eis) son ruteados hacia el datos_tabla correspondiente. Por ejemplo en la configuración de un formulario se alimenta del datos_tabla que contiene los datos que se quieren manipular, lo mismo sucede cuando se produce la modificación. El siguiente ejemplo trabaja con un solo registro por eso la simplicidad de la llamada:

      <?php
          function conf__formulario()
          {
              return $this->dep('datos')->tabla('personas')->get();
          }
          
          function evt__formulario__modificacion($datos)
          {
              $this->dep('datos')->tabla('personas')->set($datos);
          }
      ?>
  

• Cuando el CI quiere finalizar la transacción (por ejemplo el usuario decide guardar), se pide sincronizar el datos_relacion. En este caso se elige volver a la pantalla de selección luego de la sincronización.

      <?php
          function evt__procesar()
          {
              $this->dep('datos')->sincronizar();
              $this->set_pantalla('seleccion');
          }
  
      ?>
  

Estos son los pasos para escenarios sencillos, para más información sobre los servicios que brindan estos componentes se encuentra en:

• datos_relacion

• datos_tabla

Ver el funcionamiento de las clases de persistencia con un