lunes febrero 09, 2004

El patron DAO I parte

Todos nos hemos tenido que pelear alguna vez con la persistencia de nuestros datos. Yo hoy voy ha tratar este tema que me ha traido mas de un problema y mas de un dolor de cabeza, y que hoy he visto publicado en el blueprint de Java Adventure. Como siempre teneis la oportunidad/deber de corregirme.

Aunque el patron DAO es en principio un parton de J2EE, tambien puede aplicarse en cualquier aplicación que necesite mantener sus datos de forma persistente.

Proposito

El proposito del patron DAO es crear un contrato para manejar la persistencia de una informacion ocultando la implementacion de esta persistencia. En un caso ideal deberiamos crear una capa de persistencia que aislara todo acceso a información persistente.
Aislando la lógica de negocio de la capa de persistencia. Debemos el patron Data Access Object (DAO) para abstraer y encapsular los accesos, gestionar la conexiones a la fuente de datos y obtener los datos almacenados.

En este pimer post tratare lo esencial del patron DAO y como relacionarlo con otros patrones, por ejempo el Patron Factory o el Value Object. en el siguiente tratamos relacionados con la transaccionalidad y por ultimo analizare otras soluciones a la persistencia de dtaos.

Las operaciones básicas que suelen estar asociadas a la gestión de datos se denominan CRUD (create, read, update, delete).

Estrategias

Asociacion Directa
La estrategia mas simple es que a cada objeto de negocio que necesite persistencia se le asocie un objeto DAO. De esta manera un objeto Cliente tendra asocioado un objeto clienteDAO.
Un claro inconveniente de esta estrategia es que cada objeto de negocio solo puede acceder a una fuente de datos atraces de su propio DAO, asi si la fuente es una BBDD no podra cambiar a un XML

Data Access Object Factory
Para evitar lo inconvenientes de la asociacion directa podemos crear un patrón factoria[GoF] de Objetos DAO, asi podremos añadir nuevos tipos de DAOs a una clase de negocio. Por ejemplo ClienteMySQLDAO, ClienteOracleDAO o ClienteXmlDAO

Abstract Factory Data Access Object
Una forma de crear cohesion dentro de la capa de persistencia es utilizar un abstrart factory[GoF] que nos devuelva la instancia XxxfactoryDAO de cualquier objeto de negocio. Veamos el codigo de un DAOFactory típico

import javax.naming.NamingException;
import javax.naming.InitialContext;

public class DAOFactory {
public static Object getDAO(String daoEnvEntry) throws DAOSystemException { try { InitialContext ic = new InitialContext();
String className = (String) ic.lookup(daoEnvEntry);
return Class.forName(className).newInstance(); } catch (NamingException ne) { throw new DAOSystemException("DAOFactory.getDAO(" + daoEnvEntry +"): NamingException while getting DAO type : \n" + ne.getMessage()); } catch (Exception se) { throw new DAOSystemException("DAOFactory.getDAO(" + daoEnvEntry +"): Exception while getting DAO type : \n" + se.getMessage()); } } }

Transfer Object Collection


Externalizacion de las datos
El acceso a distintas fuentes de datos hace que cada objeto DAO en particular deba conocer ciertos parametros de configuracion, por ejemplo la conexion a la base de datos o una sentencia SQL. Esto lo podriamos hacer mediate un ficher properties o un archivo XML

Generalizar Data Access Object
Podemos minimizar el numero de objetos DAOs o anticiparnos a la necesidad de tener que crear nuevos objetos para distintas base de datos, si hacemos uso de la externalizacion de los parametros de configuración y creamos un objeto DAO que cargue de forma uniforme. Por ejemplo ellos DAO clienteMySQLDAO y clienteOracleDAO, solo variarian en la conexion y quizas en la consulta SQL, por lo tanto seria mejor un objeto ClienteBaseDatosDAO y un fichero que externalice la configuracion para cada BBDD

Un DAO tipico La típica arquitectura DAO suele constar al menos de

• Una clase DAO factory ejemplo
• Una interface DAO ejemplo
• Una clase concreta que implementa la interface DAOejemplo
• Algun tipo del Value objectsejemplo

ventajas

• Centralizar el control de acceso dato
• Transparencias en el acceso a datos
• Facilita la migracion
• organiza todos los accesos a datos en una capa separada

desventajas

• Añade una nueva capa
• Necesita crearse una geraquia de clases
• Aumenta la complegidad del diseño inicial

( feb 09 2004, 03:50:43 PM CET ) Permalink Comentarios [6]