Data Access Object

Muchas aplicaciones J2EE utilizan datos persistentes en algún momento. Este almacenamiento persistente se puede implementar mediante diferentes mecanismos, y cada uno de ellos tiene sus propios APIs para acceder a los datos. Además, muchas aplicaciones necesitan acceder a datos que residen en otros sistemas (mainframe, repositorios LDAP, etc.)

Dentro incluso de un mismo tipo de almacenamiento, como son los sistemas de gestión de bases de datos relacionales (SGBDR), podemos encontrar variaciones en la forma de consultar y manipular los datos. Aunque las aplicaciones desarrolladas en java pueden utilizar el API JDBC y el lenguaje SQL para acceder a los datos almacenados un SGBDR, el formato o sintaxis de las sentencias SQL pueden variar dependiendo del RDBMS en particular.

Si, además, las aplicaciones usan diferentes tipos de almacenamientos persistentes (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc.), existe aún más diversidad entre las distintas APIs que necesitan y sus características.

Al codificar las llamadas a estos APIs, desde los componentes una aplicación, se creará una dependencia directa entre el código de los componentes de la aplicación y el código de acceso a los datos. Este acoplamiento, haría difícil y tedioso migrar la aplicación de un tipo de fuente de datos a otro, e implicaría cambiar los componentes para modificar el acceso a los datos.

Solución

Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos.

El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. Esta fuente de datos puede ser un almacenamiento persistente como una RDMBS, un servicio externo como un intercambio B2B, un repositorio LDAP, o un servicio de negocios al que se accede mediante CORBA Internet Inter-ORB Protocol (IIOP) o sockets de bajo nivel. Los componentes de negocio que tratan con el DAO utilizan un interface simple expuesto por el DAO para sus clientes. El DAO oculta completamente los detalles de implementación de la fuente de datos a sus clientes. Como el interface expuesto por el DAO no cambia cuando cambia la implementación de la fuente de datos subyacente, este patrón permite al DAO adaptarse a diferentes esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de negocio. Esencialmente, el DAO actúa como un adaptador entre el componente y la fuente de datos.

Implementación y colaboraciones

La representación grafica del diagrama de secuencia del patrón es la siguiente

• BusinessObject: BusinessObject representa los datos del cliente. Es el objeto que requiere el acceso a la fuente de datos para obtener y almacenar datos. Podríamos implementar un BusinessObject como un bean de sesión, un bean de entidad o cualquier otro objeto Java, además de como un Servlet o como un bean de apoyo.
• DataAccessObject: DataAccessObject es el objeto principal de este patrón. DataAccessObject abstrae la implementación del acceso a datos subyacente al BusinessObject para permitirle un acceso transparente a la fuente de datos. El BusinessObject también delega las operaciones de carga y almacenamiento en el DataAccessObject.
• DataSource: Representa la implementación de la fuente de datos. Una fuente de datos podría ser una base de datos como un RDBMS, un OODBMS, un repositorio XML, un fichero plano, etc. También lo pueden ser otros sitemas (mainframes/legales), servicios (servicio B2B u oficina de tarjetas de crédito), o algún tipo de repositorio (LDAP).
• TransferObject: Representa un TransferObject utilizado para el transporte de datos. DataAccessObject podría utilizar un TransferObject para devolver los datos al cliente. El DataAccessObject también podría recibir datos desde el cliente en un TransferObject para actualizar los datos en la fuente de datos.