...quiere decir una clase cuyos instancias (objetos) puedan salvar su estado en un medio persistente (como un archivo o base de datos) para un momento posterior se pueda recrear ese objeto.
Me propongo en esta ocasión guardar el estado de los objetos en alguna base de datos (los ejemplos aquí expuestos están en MySql).
Miremos primeramente el lado de la base de datos (el modelo relacional). Me enseñaron en la Poli lo importante que es el álgebra relacional y la normalización, que se resume en la definición de las tablas, una clave primaria, una o más clave alternas y externas así como cuidar de la integridad relacional entre tablas. Todo esto mas un buen criterio en modelamiento es la base de conocimiento de todo niño informático que dice de sí mismo ser un “hacker”.
Hace años, en algún momento aprendí que era mejor no perder tiempo en la búsqueda una clave primaria, y dejar que cada tabla tenga una columna con valores enteros únicos a la que se la llama “Id” y que sea éste campo la clave primaria. Se incrementa en 1 cada vez que se agrega un nuevo registro. Esto no impide que invierta mi tiempo en buscar índices en base a claves únicas que son la base de la eficiencia.
Por ejemplo: en una tabla con la información de licencias de manejo al menos tendrá dos claves: Id, que es la clave primaria, y el número de licencia que es una clave alterna única. Crear un nuevo registro impone un nuevo valor Id sobre una base secuencial (máximo Id + 1). Actualizar un registro significa buscarlo en base al campo Id para actualizarlo. Cargar un registro implica aplicar un criterio de búsqueda, encontrarlo y recordar su Id con el propósito de actualizarlo o borrarlo. A esto voy a agregar otra columna de control,”version”, de tal manera que cada que ejecute una sentencia sql “update…” este campo se incrementa en la unidad.
create table licencia (
Id int,
version int,
numero varchar(16),
-- otros campos
primary key(Id));
)
(ingresando datos tendríamos...)
+------+---------+------------+- - -
| Id | version | numero | ....
+------+---------+------------+- - -
| 1 | 1 | 2190033333 |
| 2 | 1 | 9012227615 |
| 3 | 1 | 7810289387 |
+------+---------+------------+- - -
Miremos ahora la definición de la clase (para variar... en groovy). Si quiero que un objeto sea persistible, entonces no se me ocurre otra cosa que replicar los campos “Id” y “version” del modelo relacional a la definición de clase:
1 class licencia { 2 int Id 3 int versión 4 String numero 5 // ... otros campos 6 // ... otros métodos 7 }
Esta clase no debería contener sentencias SQL relacionadas con persistencia para mantenerla como elemento del dominio de la aplicación, que absorba todo la complejidad de la lógica de negocios sin mezclar código de persistencia.
Entonces... ¿dónde está el código que carga (load), guarda (save) o elimina (delete) un objeto?, en otra clase llamada licencia_ORM que contiene todos esos métodos, y que debería manejarse a nivel de comandos:
1 licencia_ORM orm = new licencia_ORM() 2 licencia lic = new Licencia() 3 4 lic = orm.load('Id = 1') 5 // 6 // operaciones del dominio de negocios sobre el objeto 'lic' 7 // 8 orm.save lic
para los iniciados
Por algunas razones prefiero este esquema de persistencia a algunos frameworks:
- Menos dependencias
- La clase licencia_ORM es generable y es el punto claro donde defino las sentencias SQL de persistencia.
- Excepto por los campos “Id” y “version” la clase licencia en el dominio de negocios está alejada de anotaciones que afectan la visibilidad del código.
- Se me ocurre que aspectos de la clase licencia_ORM pueden ser controlados mediante "metaclase" en groovy.
- Este mecanismo lo utilicé inicialmente en Delphi y créanme ¡ jamás me ha fallado !
