Que es Data Access Object
Introducción
La mayoría de las aplicaciones, tienen que persistir datos en algún momento, ya sea serializándolos, guardándolos en una base de datos relacional, o una base de datos orientada a objetos, etc. Para hacer esto, la aplicación interactúa con la base de datos. El "como interactúa" NO debe ser asunto de la capa de lógica de negocio de la aplicación, ya que para eso está la capa de persistencia, que es la encargada de interactuar con la base de datos. Sabiendo esto, podemos decir que DAO es un patrón de diseño utilizado para crear esta capa de persistencia.
Pero... ¿de qué sirve tener una capa de persistencia?
Bueno, imaginemos que hicimos una aplicación de gestión para nuestra empresa. Utilizando como motor de base de datos Oracle. Pero no tenemos dividida la capa de lógica de negocio de la de persistencia. Por lo que la interacción con la base de datos se hace directamente desde la capa de lógica de negocio. Nuestra aplicación consiste en muchísimas clases, y gran parte de ellas interactúan con la base de datos (conectándose a la base de datos, guardando y recuperando datos, etc.).
Nuestra aplicación va de maravilla, cuando de pronto, se acerca nuestro querido jefe y nos comenta que por X, Y y Z razones se va a cambiar el motor de la base de datos a PostgreSQL. En ese momento nos retiraríamos sigilosamente hacia la heladera más cercana para abrirla descalzos y con los pies mojados.
Si hubiéramos tenido por separado la capa de lógica de negocio de la de persistencia, habría sido suficiente con modificar la capa de persistencia para que la aplicación pudiera utilizar el nuevo motor de base de datos, sin tener que modificar nada de la capa de lógica de negocio. Pero como en el ejemplo anterior NO usamos una capa de persistencia, sino que interactuamos con la base de datos directamente desde la capa de lógica de negocio, entonces vamos a tener que modificar todas las clases, cambiando todas las consultas SQL, la manera de acceder a la base de datos, etc. para adecuarse al nuevo motor de la base de datos.
Bien, ahora que sabemos porque es importante tener separadas las capas de lógica de negocio y de persistencia, vamos a ver como utilizar el patrón de diseño DAO para crear nuestra propia capa de persistencia.
Como funciona DAO
Como dijimos antes, DAO encapsula el acceso a la base de datos. Por lo que cuando la capa de lógica de negocio necesite interactuar con la base de datos, va a hacerlo a través de la API que le ofrece DAO. Generalmente esta API consiste en métodos CRUD (Create, Read, Update y Delete). Entonces por ejemplo cuando la capa de lógica de negocio necesite guardar un dato en la base de datos, va a llamar a un método create(). Lo que haga este método, es problema de DAO y depende de como DAO implemente el método create(), puede que lo implemente de manera que los datos se almacenen en una base de datos relacional como puede que lo implemente de manera que los datos se almacenen en ficheros de texto. Lo importante es que la capa de lógica de negocio no tiene porque saberlo, lo único que sabe es que el método create() va a guardar los datos, así como el método delete() va a eliminarlos, el método update() actualizarlos, etc. Pero no tiene idea de como interactúa DAO con la base de datos.
En una aplicación, hay tantos DAOs como modelos. Es decir, en una base de datos relacional, por cada tabla, habría un DAO.
DAO consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan los métodos CRUD para realizar las "4 operaciones básicas" de una base de datos.
Bien, nos falta comprender algo más para poder empezar a ver código. Los DTO (Data Transfer Object) o también denominados VO (Value Object). Son utilizados por DAO para transportar los datos desde la base de datos hacia la capa de lógica de negocio y viceversa. Por ejemplo, cuando la capa de lógica de negocio llama al método create(), ¿qué es lo que hace DAO? inserta un nuevo dato... ¿pero qué dato? el que la capa de lógica de negocio le pase como parámetro... ¿y cómo se lo pasa este dato? bueno, a través de un DTO.
Podría decirse que un DTO es un objeto común y corriente, que tiene como atributos los datos del modelo, con sus correspondientes accessors (getters y setters).
Por ejemplo, si tuviéramos una base de datos relacional con una tabla employers, con los campos id, name y salary. Entonces tendríamos que crear una clase EmployerDTO, con los atributos id, name y salary, que van a utilizar la capa de negocio y de persistencia para transportar los datos entre las dos capas.
Entonces cuando la capa de lógica de negocio quiera guardar un dato en la base de datos, va a crear un objeto EmployerDTO, a través de los accessors va a modificar los atributos, y después se lo va a pasar al método create() de DAO. Entonces DAO va a leer los datos del DTO, y los va a guardar en la base de datos. Lo mismo pasaría para eliminar datos. Y para actualizarlos además se le pasaría el ID, para saber que dato actualizar. Para buscar datos, sería parecido, ya que se le pasa al método read() el DTO para usarlo como patrón de búsqueda, pero con la diferencia de que este método tiene valor de retorno, ya que devuelve otro DTO con los datos del resultado de la búsqueda.
Este articulo fue tomado de:
DAO
- Richardmx's blog
- Inicie sesión o regístrese para enviar comentarios
Bien
Da gusto ver articulos como este, en vez de tantos "blogs" de "tengo una duda por favor alguien puede hacerme mi tarea de primer semestre?"
Con esto te puedes seguir despues a explicar ORM, o MVC o algunos otros esquemas de separacion de modulos (capas, etc). Ese caso que estás diciendo es bastante común (lo de que te cambian de base de datos) y por eso hay tantas herramientas (tanto software como maneras de hacer las cosas) que te abstraen de la base de datos que uses.
Given the choice of dancing pigs and security, users will choose dancing pigs, every single time. - Steve Riley
Muy buen
Muy buen artículo.
Excelente la explicación, muy entendible. Sería bueno como dice ezamudio tener más conceptos de ese tipo aquí.
Saludos!
--
Javier Benek
Una Duda
Suena muy similar a MVC, cual es la diferencia fundamental?
Que el DAO se usa en la M
Que el DAO se usa en la M del MVC
Mas sobre MVC y DAO
Buenas tardes,
Peuden ampliarme el panorama, de la diferencia entre DAO y MVC.
De antemano muchas gracias.
El DAO es para datos unicamente.
El DAO ( Data Acces Object - Objeto de Acceso a Datos ) es un patrón de diseño para "acceder a los datos" unicamente.
El MVC es una mmnhh "arquitectura" donde se separa en diferentes capas el Modelo, la Vista y el Controlador.
La diferencia pues es que el MVC 1) No es un patrón de diseño, 2) No sirve ( unicamente ) para acceder a los datos, es mucho más amplio y el DAO es limitado en el sentido que solo se usa precisamente para los datos.
Otro ejemplo en donde se ve la utilidad del DAO, es que puedes cambiar el mecanismo de persistencia sin tener que cambiar la interfaz del objeto. Esto es, puedes por ejemplo usar archivos planos, un XML, un socket, un webservice o una base de datos para guardar la información y el DAO permite "abstraer" estas diferencias para que el cliente ( quién lo usa ) no se entere.
Un ejemplo puede ser así. Supongamos que tenemos un objeto que sirve para obtener la información de un usuario.
Tendría para este ejemplo un método "getUser" y recibe como parametro su nombre.
Las diferente simplementaciones de este DAO pueden obtener el usuario de forma diferente, uno podría sacarlo de una base de datos:
O puede sacarlo de un archivo:
O de un socket:
El DAO, finalmente hace el trabajo de obtener los datos de alguna manera. El cliente puede usarlo simplemente así:
Como ves, el código simplemente usa el Dao, pero no tiene más información de donde vienen los datos ( archivo, socket o base de datos ) de esta manera permite variar la implementación y le dá más flexibilidad. Quizá en este pequeño ejemplo no se note, pero hay aplicaciones que pueden necesitarlo.
Por otro laaado el MVC. ufff, pues digamos que NO es esto que puse :P :P Tapestry es un framework MVC, como puedes suponer, es mucho más completo.
Gracias Oscar
Como siempre muy ejemplificada y entendible tu respuesta.
Me queria saltar directo a faceles, pero en lo personal me gustaria entender y hacer un pequeno sistemita en jsp (no esta de mas),pero entre servlet, dataManager y web.xml ,todo esto con MVC; me trae hecho bolas.
jaja saludos @Francisco, yo
jaja saludos @Francisco, yo tambien ando empezando con esto y si es complicado pero con un poco de orden y sobre todo mucha practica ningun webApp nos ganara (palabras sabias del maestro @Rugi) y gracias @Oscar muy buena explicacion me queda clarito clarito!!
Cliente web service desde Dao
Siguiendo tu fabrica de daos ¿Colocarías un cliente de web service desde un dao ...?, se ve un poco raro pero suena lógico.
Si, en términos generales
Si, en términos generales puedes tener o clasificar tus webservices en distintas categorías. Puedes tener WS de "alto" nivel ( ejemplo un WS de punto de venta ) o un WS de muy bajo nivel ( ejemplo, sacar información de un usuario ) y puedes también tener WS "intermedios".
Puedes usar uno de estos WS de bajo nivel, para obtener datos nadamas y esconderlo detras de un DAO.
Para un WS de alto nivel, no hace mucho sentido, por que ese WS es más completo/complejo y esta más bien para ser usado como un todo.
Duda
Sobre el Tema de MVC, dado que estoy haciendo mi pequeña aplicación MVC con JSP, tengo la siguiente duda espero me puedan ayudar:
Quiero pasar los parámetros de conexión a la Base de Datos desde el web.xml.
Mi duda es ¿quien tiene que interceptar los parámetros y crear el objeto
y como le hago para interpretar los parámetros?.
De antemano gracias.
@francisco: sobre el MVC.
Esta pregunta se merece su propio post en los foros :)
@OscarRyz
@OscarRyz tiene razon. Aprovecho para Felicitarte Oscar das muy bien explicaciones, mas que "mis maestros de sistemas".
Saludos.
Menos mal.
A veces pienso "Ya ni me han de estar leyendo a esta altura..." y le hago refactoring a mi explicación.
Que bueno que da resultado y les sea útil.
En donde entran los DAO's
Les dejo una imagen de los Core J2EE Patterns:
aca el link de SUN/ORACLE:
corej2eepatterns
Están en inglés. Por eso se agradece la aportación de explicarlo en español ;)
Saludos
pacovr
Duda
Buenas noches,
Por favor sáquenme de la duda, esta página veo que usa DAO, yo veo que si, pero quiero saber si realmente esta usando MVC.
De antemano gracias.
Me respondo
Me respondo a mi mismo, leyendo el comentario de @OscaRyz ya ubique como el DAO se usa en el modelo de MVC, esto lo hace creando las Interfaces.
Esto esta machetudo pero interesante.
Saludos
opiniones diferentes
Interesante como se llegan a encontrar diferentes opiniones acerca del MVC y la programación en capas... en forosdelweb se puede encontrar opiniones de personas que aparentemente son expertos e indican que MVC NO es una arquitectura, contrario a lo que dice OscarRyz, sino un Patrón de diseño
Felicidades por la explicación Oscar.
Pff... digamos que el MVC SI
Pff... digamos que el MVC SI es "patrón" pero de arquitectura y el DAO es un patrón de diseño de software ¬¬
Para acabar pronto, un patrón de arquitectura es más amplio que uno de diseño de software.
Para aumentar la confusión existen frameworks que utilizan esta arquitectura, por lo tanto son frameworks MVC.
Pero en este tipo de cosas no vale la pena enfrascarse mucho. Basta con pensar que hay quién pone como ejemplo de MVC, un browser, donde el HTML es el modelo, el CSS la vista y el browser mismo el controlador pfff!!. Y no es cualquier persona la quíen lo dice. Por otro no es del todo incorrecto su ejemplo, pero eriza el cabello pensarlo así.
Patrones, estilos, arquitecturas, etc.
Existen muchas formas de calificar las soluciones que usamos para lograr un diseño arquitectónico correcto de las aplicaciones que construimos. Patrones de diseño, patrones arquitectónicos, estilos arquitectónicos, arquitecturas, idioms, son algunas de esas categorías.
Depende mucho de la visión del autor (pienso en autores expertos en la materia) para, por ejemplo, decir que MVC es un patrón o una microarquitectura o un estilo arquitectónico, u otra cosa.
Como todos esos conceptos están relacionados con la arquitectura de software, y existen muchas formas de entender lo que es arquitectura, sucede entonces que también hay muchas formas de encasillar a MVC, y lo interesante es que ninguna está realmente mal.
Basta con revisar la forma en que, por ejemplo el SEI (el instituto más rankeado en Arquitectura de Software), trata el tema de Arquitectura y confrontarlo con la manera en que las guías de arquitectura de aplicaciones de Microsoft lo hace, o como lo hace Java EE y los catálogos de patrones que se han escrito para Java EE.
Decir entonces que MVC es un patrón de diseño pero no un patrón arquitectónico o que es un patrón arquitectónico pero no un patrón de diseño es pararse en una cuerda floja donde de un lado tienes al diseño y en otro lado la arquitectura, y caemos entonces en distinguir entre diseño y arquitectura de manera tajante, algo que aun nadie ha logrado.
Entonces creo que lo mejor es entender lo que es MVC desde la perspectiva de separar tres partes importantes de cualquier aplicación de software y ver si algunos de los patrones de diseño que se discuten en varios catálogos aplican esa separación.
Es el caso del patrón Service To Worker del catálogo de patrones de J2EE. Algunos dicen que Service to Worker es un "patrón de diseño basado en MVC para centralizar el control y el manejo de solicitudes para obtener un modelo de presentación antes de pasar el control a la vista.
Pero noten lo que dice: "un patrón de diseño basado en MVC". ¿Será entonces MVC un estilo?
Si vamos más allá, el propio Service To Worker es un combinación de otros patrones de diseño. ¿Es el Service to Worker un patrón o una combinación de patrones?
Podría poner más ejemplos. El patrón Template Method, descrito como patrón de diseño es para muchos un idioms de como escribir un algoritmo con pasos redefinibles en clases derivadas. Para muchos el patrón Singleton es otro idiom.
Si el término patrón lo entendemos como la descripción de una solución a un problema recurrente en un contexto, entonces MVC es uun patrón. Si entonces alguien me pregunta si es de diseño o arquitectónico, mi respuesta es: discutamos las diferencias y similitudes entre diseño y arquitectura para entonces ubicar al susodicho MVC.
Es muy probable que después de esa discusión, algunos digan que es de diseño y otros que es arquitectónico. Todos tendrán razón.