En el software de computadora , un objeto de acceso a datos ( DAO ) es un patrón que proporciona una interfaz abstracta a algún tipo de base de datos u otro mecanismo de persistencia. Al asignar las llamadas de la aplicación a la capa de persistencia, el DAO proporciona algunas operaciones de datos específicas sin exponer los detalles de la base de datos. Este aislamiento respalda el principio de responsabilidad única . Separa qué acceso a datos necesita la aplicación, en términos de objetos y tipos de datos específicos del dominio (la interfaz pública de la DAO), de cómo estas necesidades pueden satisfacerse con un DBMS específico , esquema de base de datos, etc. (la implementación del DAO).
Aunque este patrón de diseño es igualmente aplicable a la mayoría de los lenguajes de programación, a la mayoría de los tipos de software con necesidades de persistencia y a la mayoría de los tipos de bases de datos, tradicionalmente se asocia con aplicaciones Java EE y con bases de datos relacionales (a las que se accede a través de la API JDBC debido a su origen en Sun Las pautas de mejores prácticas de Microsystems [1] "Core J2EE Patterns" para esa plataforma).
Ventajas
La principal ventaja de utilizar objetos de acceso a datos es la separación relativamente simple y rigurosa entre dos partes importantes de una aplicación que pueden, pero no deben, saber nada entre sí, y de las que se puede esperar que evolucionen con frecuencia e independientemente. El cambio de la lógica empresarial puede depender de la misma interfaz DAO, mientras que los cambios en la lógica de persistencia no afectan a los clientes DAO siempre que la interfaz permanezca correctamente implementada.
Todos los detalles del almacenamiento están ocultos al resto de la aplicación (ver información oculta ). Por lo tanto, los posibles cambios en el mecanismo de persistencia se pueden implementar simplemente modificando una implementación de DAO mientras que el resto de la aplicación no se ve afectada. Los DAO actúan como intermediarios entre la aplicación y la base de datos. Mueven datos de un lado a otro entre objetos y registros de bases de datos. La prueba unitaria del código se facilita sustituyendo el DAO con un doble de prueba en la prueba, lo que hace que las pruebas sean independientes de la capa de persistencia.
En el contexto general del lenguaje de programación Java , los objetos de acceso a datos como concepto de diseño se pueden implementar de varias formas. Esto puede variar desde una interfaz bastante simple que separa las partes de acceso a los datos de la lógica de la aplicación, hasta marcos y productos comerciales. Los paradigmas de codificación DAO pueden requerir cierta habilidad. Tecnologías como Java Persistence API y Enterprise JavaBeans vienen integradas en servidores de aplicaciones y pueden usarse en aplicaciones que usan un servidor de aplicaciones JavaEE. Los productos comerciales como TopLink están disponibles basados en el mapeo relacional de objetos (ORM). El software ORM de código abierto más popular incluye implementaciones de Doctrine , Hibernate , iBATIS y JPA como Apache OpenJPA .
Desventajas
Las posibles desventajas de usar DAO incluyen abstracción con fugas , duplicación de código [ cita requerida ] e inversión de abstracción . En particular, la abstracción del DAO como un objeto Java normal puede ocultar el alto costo de cada acceso a la base de datos y también puede obligar a los desarrolladores a activar múltiples consultas a la base de datos para recuperar información que, de otro modo, podría devolverse en una sola operación utilizando operaciones de conjuntos de SQL . Si una aplicación requiere múltiples DAO, uno puede encontrarse repitiendo esencialmente el mismo código de creación, lectura, actualización y eliminación para cada DAO. Sin embargo, este código de placa de caldera puede evitarse implementando un DAO genérico que maneje estas operaciones comunes. [2]
Escenario de uso hipotético
Imagine una situación en la que es propietario de una empresa exitosa que ha recibido contratos para desarrollar una aplicación para dos clientes diferentes. Las especificaciones de la aplicación son casi idénticas para los dos clientes. Ambos clientes administran datos usando bases de datos SQL, pero una compañía usa una base de datos propietaria y la otra usa una alternativa de código abierto, lo que implica que la capa de persistencia de su aplicación deberá implementarse de dos maneras diferentes. Además, a medida que surgen nuevos clientes, es posible que se necesiten implementaciones adicionales. En este caso, el uso del patrón de objeto de acceso a datos garantizaría la cantidad correcta de abstracción y encapsulación requerida para acceder a cualquiera de las diferentes bases de datos de backend.
Herramientas y marcos
- Sistema de mapeo relacional de objetos (ORM) basado en compilador ODB para C ++
- ORMLite: marco ligero de mapeo relacional de objetos (ORM) en Java para JDBC y Android [3]
- Microsoft Entity Framework
- DBIx :: Módulo de mapeo relacional de objetos (ORM) de clase para Perl
- TuxORM: biblioteca de mapeo relacional de objetos (ORM) simple en Java para JDBC
Ver también
Referencias
- ^ "Core J2EE Patterns - Data Access Objects" . Sun Microsystems Inc. 2007-08-02.
- ^ Consulte http://www.ibm.com/developerworks/java/library/j-genericdao/index.html para conocer las soluciones
- ^ Hodgson, Kyle; Reid, Darren (23 de enero de 2015). Libro de cocina ServiceStack 4 . Packt Publishing Ltd. pág. Capítulo 4. ISBN 9781783986576. Consultado el 22 de junio de 2016 .