Patrón DAO

Introducción

El problema que viene a resolver este patrón es el de contar con diversas fuentes de datos (base de datos, archivos, servicios externos, etc). De tal forma que se encapsula la forma de acceder a la fuente de datos. Este patrón surge históricamente de la necesidad de gestionar una diversidad de fuentes de datos, aunque su uso se extiende al problema de ancapsular no sólo la fuente de datos, sino además ocultar la forma de acceder a los datos. Se trata de que el software cliente se centre en los datos que necesita y se olvide de cómo se realiza el acceso a los datos o de cual es la fuente de almacenamiento.

Objetivo y aplicabilidad

Las aplicaciones pueden utilizar el API JDBC para acceder a los datos de una base de datos relacional. Este API permite una forma estándar de acceder y manipular datos en una base de datos ralacional. El API JDBC permite a las aplicaciones J2EE utilizar sentencias SQL, que son el método estándar para acceder a tablas y vistas. La idea de este patrón es ocultar la fuente de datos y la complejidad del uso de JDBC a la capa de presentación o de negocio.

Un DAO define la relación entre la lógica de presentación y empresa por una parte y por otra los datos. El DAO tiene un interfaz común, sea cual sea el modo y fuente de acceso a datos.

Solución (diagrama de clases) e implementación (código ejemplo)

La idea de este patrón es sencilla. En primer lugar, debemos hacernos las clases que representan nuestros datos. Por ejemplo, podemos hacer una clase Persona con los datos de la persona y los métodos set() y get() correspondientes.

Luego hacemos una interface. Esta interface tiene que tener los métodos necesarios para obtener y almacenar Personas. Esta interface no debe tener nada que la relaciones con una base de datos ni cualquier otra cosa específica del medio de almacenamiento que vayamos a usar, es decir, ningún parámetro debería ser una Connection, ni un nombre de fichero, etc. Por ejemplo, puede ser algo así public interface InterfaceDAO { public List<Persona> getPersonas(); public Persona getPersonaPorNombre (String nombre); ... public void salvaPersona (Persona persona); public void modificaPersona (Persona persona); ... public void borraPersonaPorNombre (String nombre); ... }

y todos los métodos con todas las variantes que necesitemos en nuestra aplicación.

Con esto deberíamos construir nuestra aplicación, usando la clase Persona y usando la InterfaceDAO para obtener y modificar Personas.

Aparte, hacemos la implementación de la InterfaceDAO, ya contra una base de datos concreta o usando una herramienta -iBATIS, Hibernate, etc- determinada. Al usar nuestra aplicación la InterfaceDAO, podremos pasarle cualquier implementación que queramos o incluso cambiar una por otra en un momento dado.

Por ejemplo, podemos hacer implementaciones según usemos MySQL, Oracle, etc

o bien según usemos iBATIS, JDBC, Hibernate, etc.

Normalmente el patrón DAO se completa con algún tipo de Factoría: Una clase a la que al pedirle la InterfaceDAO decide cual de las implementaciones instanciar y la devuelve. public class FactoriaDAO { public static InterfaceDAO getDAO() { if (baseDatos.equals("oracle") return new ImplementacionDAOOracle (parametrosConexionOracle); else if (baseDatos.equals("MySQL") return new ImplemetancionDAOMySQL (parametrosConexionMySQL); ...

} }

Otra opción es que las clases de nuestra aplicación tengan un método setInterfaceDAO() y que alguien desde fuera instancie la implementación concreta y se la pase.

Conclusión

El patrón DAO se puede utilizar para separar el uso de los datos de su almacenamiento real. Proporciona soporte para muchos tipos de fuentes de datos si se utiliza junto con el patrón de la fábrica. El uso del objeto de acceder a los datos también pueden fomentar el

...