Hace mucho tiempo que quería escribir este artículo sobre el DAO, pero no había tenido el impulso necesario para hacerlo. No sé bien lo que me impulsa ahora, pero aquí está.
Luego de averiguar por todo lado la mejor manera de hacer esto (conectarse y recuperar datos de una BD de manera ordenada y escalable) descubrí el DAO, un poco tarde ya que al año siguiente salió la versión beta de JPA y claro, todo el DAO se derrumbó (o comenzó a derrumbarse...)
La versión de JAVA basa todo su modelo en esta relación fundamental de 4 componentes:
En el caso del DAO con todas las recomendaciones integradas, tendrás un grupo de clases (DAO, DTO y otras de acuerdo a implementación) por tabla (por ejemplo Persona) por motor de base de datos o persistencia que desees utilizar: XML, Mysql, archivos, etc; donde no necesitas más que lo siguiente para hacer un select * from:
Lo elegante es que no necesitas SQL en ningún lugar y puedes tener la librería de los DAO aparte.
Pero veamos en detalle este modelo:
Primero podemos observar el modelo de DTO (la object-ivización de la tabla BTNombres en este caso).
También se ve el modelo de Factory que se debe crear (una implemetnación de Factory por persistencia utilizada).
En la siguiente figura:
Se puede ver el modelo de los DAO, BTNombresDAO es la clase que tiene todo el actualizar, seleccionar, eliminar....
Cómo fue que se pudo hacer esto si aplica a tablas diferentes?
1. Todas las tablas tienen un id, un campo que se llama id de tipo entero que funciona de llave
2. La superclase es en realidad una clase generic
De esta manera, el código para hacer el update al registro 3 de la tabla Persona se hace así:
Nuevamente vemos la elegancia de evitar el uso de SQL y la independencia con la conexión: no sabemos si escribe a un fichero, una base de datos, etc.
Para fines más laborales, he creado un generador de capa de datos que sigue el mismo modelo (lo único es que genera csharp y no java... oops), que toma en cuenta también lo siguiente:
- Código para aplicar Logs con log4net
- Los updates solamente se hacen sobre los campos que han cambiado y no sobre todas las columnas de un registro (util para ciertos análisis en algunas bases de datos)
- Posiblidad de realización de transacciones con modelo similar (aumentando dos líneas de código).
La última línea habla de transacciones, sin embargo, todo eso quedó atrás con el Java Transaction y el Java Persistence, por ello el título del artículo.
EL generador y más explicaciones sobre el modelo los subiré en unas semanas a sourceforge (anunciado aquí también). Pero para los impacientes les puedo pasar un código super desprolijo pero que hace el trabajo :-)
Luego de averiguar por todo lado la mejor manera de hacer esto (conectarse y recuperar datos de una BD de manera ordenada y escalable) descubrí el DAO, un poco tarde ya que al año siguiente salió la versión beta de JPA y claro, todo el DAO se derrumbó (o comenzó a derrumbarse...)
La versión de JAVA basa todo su modelo en esta relación fundamental de 4 componentes:
En el caso del DAO con todas las recomendaciones integradas, tendrás un grupo de clases (DAO, DTO y otras de acuerdo a implementación) por tabla (por ejemplo Persona) por motor de base de datos o persistencia que desees utilizar: XML, Mysql, archivos, etc; donde no necesitas más que lo siguiente para hacer un select * from:
FactoryDAO factory = FactoryDAO.getOrCreate();
PersonaDAO dao = factory.newPersonaDAO();
Vector lista = dao.getTodos();
Lo elegante es que no necesitas SQL en ningún lugar y puedes tener la librería de los DAO aparte.
Pero veamos en detalle este modelo:
Primero podemos observar el modelo de DTO (la object-ivización de la tabla BTNombres en este caso).
También se ve el modelo de Factory que se debe crear (una implemetnación de Factory por persistencia utilizada).
En la siguiente figura:
Se puede ver el modelo de los DAO, BTNombresDAO es la clase que tiene todo el actualizar, seleccionar, eliminar....
Cómo fue que se pudo hacer esto si aplica a tablas diferentes?
1. Todas las tablas tienen un id, un campo que se llama id de tipo entero que funciona de llave
2. La superclase es en realidad una clase generic
De esta manera, el código para hacer el update al registro 3 de la tabla Persona se hace así:
FactoryDAO factory = FactoryDAO.Instancia;
PersonaDAO dao = factory.newPersonaDAO();
PersonaDTO objPersona = dao.seleccionar(3);
objPersona.setNombre("Pedro");
dao.actualizar();
Nuevamente vemos la elegancia de evitar el uso de SQL y la independencia con la conexión: no sabemos si escribe a un fichero, una base de datos, etc.
Para fines más laborales, he creado un generador de capa de datos que sigue el mismo modelo (lo único es que genera csharp y no java... oops), que toma en cuenta también lo siguiente:
- Código para aplicar Logs con log4net
- Los updates solamente se hacen sobre los campos que han cambiado y no sobre todas las columnas de un registro (util para ciertos análisis en algunas bases de datos)
- Posiblidad de realización de transacciones con modelo similar (aumentando dos líneas de código).
La última línea habla de transacciones, sin embargo, todo eso quedó atrás con el Java Transaction y el Java Persistence, por ello el título del artículo.
EL generador y más explicaciones sobre el modelo los subiré en unas semanas a sourceforge (anunciado aquí también). Pero para los impacientes les puedo pasar un código super desprolijo pero que hace el trabajo :-)
Comentarios