CENTRO UNIVERSITARIO UAEM ATLACOMULCO

LICENCIATURA EN:

INGENIERÍA EN COMPUTACIÓN

“Paradigmas de Programación I”

TERCER SEMESTRE

ALUMNO: Gabriel Sánchez Hernández

DOCENTE: Julio Alberto de la Teja López

Grupo: ICO 26

No. Cuenta: 2124687

Periodo Educativo: 2022-B

Atlacomulco de Fabela, 04 de noviembre del 2022

Objeto de Acceso a Datos (DAO)
Definición:
Objeto de acceso a datos ( DAO ) es un objeto que proporciona un resumen de interfaz a algún tipo de base de
datos u otro mecanismo de persistencia. Por las llamadas de solicitud de asignación a la capa de persistencia, DAOs
proporcionar algunas operaciones de datos específicos sin exponer a los detalles de la base de datos. Este
aislamiento apoya el principio de la responsabilidad individual . Separa los datos que accede a las necesidades de
la aplicación, en términos de objetos específicos del dominio y tipos de datos (la interfaz pública de la DAO), y cómo
estas necesidades pueden ser satisfechas con una específica DBMS , el esquema de base de datos, etc (la aplicación
de la DAO).
Aunque este patrón de diseño es igualmente aplicable a la mayoría de los lenguajes de programación, la mayoría
de los tipos de software con las necesidades de persistencia, y la mayoría de los tipos de bases de datos, se asocia
tradicionalmente con Java EE aplicaciones y bases de datos relacionales se accede a través de la API de JDBC, debido
a su origen en Sun Microsystems «Guías de buenas prácticas («Core J2EE Patterns») para esa plataforma.
Funcionamiento:

• DAO encapsula el acceso a la base de datos. Por lo que cuando la capa 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 (Crear, Leer, Actualizar y Eliminar). 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
créate().
• 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.
Ventajas:
La ventaja de utilizar objetos de acceso a datos es la separación relativamente simple y riguroso entre dos partes
importantes de una aplicación que puede y debe saber casi nada el uno del otro, y que se puede esperar que
evolucione con frecuencia y de forma independiente. Cambio de la lógica de negocio puede depender de la misma
interfaz DAO, mientras que los cambios en la lógica de persistencia no afectan a los clientes DAO, siempre y cuando
la interfaz sigue siendo implementado correctamente.

• Se puede utilizar en un gran porcentaje de aplicaciones – en cualquier lugar se requiere el almacenamiento

de datos.
• Ocultar todos los detalles de almacenamiento de datos desde el resto de la aplicación.
• Actuar como intermediario entre la aplicación y la base de datos. Se mueven los datos de ida y vuelta entre
los objetos y los registros de base de datos.
• Permitirá que los efectos de la ondulación de los posibles cambios en el mecanismo de persistencia que se
limita a un área específica.
Desventajas:

• La flexibilidad tiene un precio. Cuando se agregan DAO a una aplicación, la complejidad adicional de usar
otra capa de persistencia incrementa la cantidad de código ejecutado durante el tiempo de ejecución. La
configuración de las capas de persistencia requiere en la mayoría de los casos mucho trabajo.
• Las aplicaciones críticas con el rendimiento no fallan usando DAOs.
Estructura

v
Objeto de Negocio
El BusinessObject representa el cliente de datos. Es el objeto que requiere el acceso a la fuente de datos para
obtener y almacenar los datos. Un BusinessObject puede ser implementado como un bean de sesión, bean de
entidad, o algún otro objeto de Java, además de un servlet o ayudante de frijol que accede a la fuente de datos.
Objeto de acceso a datos
El DataAccessObject es el objeto principal de este patrón. El DataAccessObject abstrae la aplicación de acceso a
datos subyacentes para el BusinessObject para permitir un acceso transparente a la fuente de datos. El
BusinessObject también delega la carga de datos y operaciones de la tienda a la DataAccessObject.
Fuente de datos
Esto representa una implementación de fuente de datos. Una fuente de datos podría ser una base de datos tal
como un RDBMS, SGBDOO, repositorio XML, sistema de archivo plano, y así sucesivamente. Un origen de datos
también puede ser otro sistema (legacy / servidor), servicios (servicio de B2B o de oficinas de la carta de crédito),
o algún tipo de repositorios (LDAP).
TransferObjeto
Esto representa un Transfer Object se utiliza como soporte de datos. El DataAccessObject puede utilizar un Transfer
Object para devolver los datos al cliente. El DataAccessObject también puede recibir los datos del cliente en un
Transfer Object para actualizar los datos del origen de datos.
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.
¿Qué es un patrón de diseño?
Un patrón de diseño es una solución probada que resuelve un tipo específico de problema en el desarrollo de
software referente al diseño.
Existen una infinidad de patrones de diseño los mismos que se dividen en categorías por ejemplo: de creación,
estructurales, de comportamiento, interacción etc.
Cada uno se especializa en resolver un problema específico, si quieres profundizar y revisar todas las categorías y
ejemplos a detalle puedes visitar Design Patterns Book.
El tema es bastante extenso, que no alcanzaría una sola entrada, pero esta vez quiero hablar de los patrones MVC,
DAO, DTO que en lo personal y en la práctica considero los más utilizados al menos para el desarrollo en Java.icon

EL PATRÓN MODEL VIEW CONTROLLER O MVC

Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación,
la interfaz de usuario, y la lógica de control en tres componentes distintos.
Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de
aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo.
En español Modelo Vista Controlador, este patrón permite separar una aplicación en 3 capas, una forma de
organizar y de hacer escalable un proyecto, a continuación una breve descripción de cada capa.
Modelo: Esta capa representa todo lo que tiene que ver con el acceso a datos: guardar, actualizar, obtener datos,
además todo el código de la lógica del negocio, básicamente son las clases Java y parte de la lógica de negocio.
Vista: La vista tiene que ver con la presentación de datos del modelo y lo que ve el usuario, por lo general una vista
es la representación visual de un modelo (POJO o clase java).
Por ejemplo el modelo usuario que es una clase en Java y que tiene como propiedades, nombre y apellido debe
pertenecer a una vista en la que el usuario vea esas propiedades.
Controlador: El controlador es el encargado de conectar el modelo con las vistas, funciona como un puente entre
la vista y el modelo, el controlador recibe eventos generados por el usuario desde las vistas y se encargar de
direccionar al modelo la petición respectiva.
El modelo es el responsable de:
Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de
almacenamiento.
Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida
no está en el almacén, consultar el tiempo de entrega estándar del proveedor".
Lleva un registro de las vistas y controladores del sistema.
Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente
externo (por ejemplo, un fichero por lotes que actualiza los datos, un temporizador que desencadena una
inserción, etc.).
El controlador es responsable de:
Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer
peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método
"Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega ( nueva_orden_de_venta )".
Las vistas son responsables de:
Recibir datos del modelo y los muestra al usuario.
Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es
un modelo activo que informa de los cambios en los datos producidos por otros agentes).

• El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón,
enlace, etc.)
• El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por
el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos
(handler) o callback.
• El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la
acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los
controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las
acciones y simplifica su extensión.
• El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene
sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el
modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener
conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta
indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio.
Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo
sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque
puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene
acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
• La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
MVC en la web
Como desarrollador web, este patrón probablemente será bastante familiar, incluso si nunca lo has usado
conscientemente antes. Su modelo de datos probablemente esté contenido en algún tipo de base de datos (ya sea
una base de datos tradicional del lado del servidor como MySQL, o una solución del lado del cliente como
IndexedDB). El código de control de su aplicación probablemente esté escrito en HTML / JavaScript , y su interfaz
de usuario probablemente esté escrita usando HTML / CSS / o lo que sea. Esto se parece mucho a MVC, pero MVC
hace que estos componentes sigan un patrón más rígido.
En los primeros días de la Web, la arquitectura MVC se implementó principalmente en el lado del servidor, con el
cliente solicitando actualizaciones a través de formularios o enlaces, y recibiendo vistas actualizadas para mostrar
en el navegador. Sin embargo, en estos días, mucha de la lógica se enviaba al cliente con la llegada de los almacenes
de datos del lado del cliente, y XMLHttpRequest permitía actualizaciones parciales de la página según era necesario.
Los frameworks de desarrollo web como AngularJS y Ember.js implementan una arquitectura MVC, aunque de
maneras ligeramente diferentes.
El flujo que sigue el control generalmente es el siguiente:

Referencias:
DATA ACCESS OBJECT (DAO). (2013). Blogspot.com. http://castellanosmiguel.blogspot.com/2013/07/dataaccess-
object-dao-definicion-dao-es.html
Data Access Object | Marco de Desarrollo de la Junta de Andalucía. (2022). Juntadeandalucia.es.
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/174
Data access object. (2013, July 7). Data Access Object; Data access object.
https://ismaelgomezvelasco.wordpress.com/data-access-object-dao/data-access-object/
MVC - Glosario de MDN Web Docs: Definiciones de términos relacionados con la Web | MDN. (2022, September
5). Mozilla.org. https://developer.mozilla.org/es/docs/Glossary/MVC