El patrón Data Access Object (DAO) pretende principalmente independizar la aplicación de la forma de acceder a la base de datos, o cualquier otro tipo de repositorio de datos. Para ello se centraliza el código relativo al acceso al repositorio de datos en las clases llamadas DAO. Fuera de las clases DAO no debe haber ningún tipo de código que acceda al repositorio de datos.
Las ventajas de usar el patrón DAO son las siguientes:
Modificar el API de acceso: Se podría cambiar el acceso a la base de datos de usar JDBC a usar Hibernate y sólo habría que modificar las clases DAO no afectando al resto de la aplicación.
Modificar el repositorio de datos: Sería posible que el acceso a los usuarios se hiciera mediante LDAP a un servicio de directorio en vez de estar dichos usuarios en una base de datos relacional. Como en el caso contrario sólo sería necesario cambiar las clases DAO y el resto de la aplicación no sería necesaria modificarla.
Implementación de triggers o listeners: Al estar todo el código centralizado en las clases DAO podríamos fácilmente implementar políticas de seguridad en el acceso al repositorio de datos. Mientras que, en caso de no usarlo, sería imposible hacrlo ya que cualquiera podría acceder a los datos sin la obligación de pasar por dicha política de seguridad.
Los siguientes diagramas UML muestran ejemplos de objetos DAO.
La mayor desventaja de usar el patrón DAO es el riesgo de tener código muy similar entre los distintos objetos DAO porque, en caso de modificación o de corrección de un error, sería necesario hacer el mismo trabajo en todas las clases DAO. Por suerte, desde Java y usando Generics se reduce el código duplicado al mínimo.