DATA ACCESS OBJECT (DAO)

Es bastante normal hacer aplicaciones que almacenan y recogen datos de una base de datos. Suele ser habitual, también, querer hacer nuestra aplicación lo más independiente posible de una base de datos concreta, de cómo se accede a los datos o incluso de si hay o no base de datos detrás. Nuestra aplicación debe conseguir los datos o ser capaz de guardarlos en algún sitio, pero no tiene por qué saber de dónde los está sacando o dónde se guardan.


Hay una forma de hacer esto que ha resultado bastante eficiente en el mundo JEE y de aplicaciones web, pero que es aplicable a cualquier tipo de aplicación que deba recoger datos de algún sitio y almacenarlos. Es lo que se conoce como patrón DAO (Data Access Object).


La idea de este patrón es sencilla. En primer lugar, debemos hacernos las clases que representan nuestros datos.


Con el permiso de los más puristas, un DAO no es otra cosa que un “adaptador” o un nexo entre la lógica de negocio y la capa de persistencia (generalmente, una Base de Datos). Lo que realiza este adaptador no es otra cosa que codificar la lógica de acceso a datos de una capa de persistencia en concreto.


 Estructura
La siguiente figura muestra el diagrama de clases que representa las relaciones para el patrón DAO:

• Participantes y Responsabilidades

La siguiente figura muestra el diagrama de secuencia de la interacción entre los distintos participantes en este patrón:




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 BusinessObjectcomo 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 Transfer Object utilizado para el transporte de datos. DataAccessObjectpodría utilizar un Transfer Object para devolver los datos al cliente. El DataAccessObjecttambién podría recibir datos desde el cliente en un Transfer Object para actualizar los datos en la fuente de datos.

PATRONES DE DISEÑO

PATRONES DE DISEÑO


Para definir un patrón se puede partir de la definición que Christopher Alexander hizo en su libro:

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”

                                                                                               – Christopher Alexander


Un patrón de diseño se puede ver como una solución repetitiva y experta a problemas recurrentes, es decir, estrategias que se conocen desde un principio y se sabe qué tipo de problemas van a solucionar.


Una característica fundamental de los patrones de diseño es que surgen de la experiencia de la comunidad de programadores. De esta forma, los patrones son soluciones que se han probado en proyectos reales, y hay consenso sobre su utilidad.


Existen diferentes definiciones por cada autor, pero los patrones tienen algunas características identificadas como:

• Los patrones son identificados a partir de la experiencia humana. 
• Los patrones previenen reinventar la rueda. 
• Los patrones existen en diferentes niveles de abstracción. 
• Los patrones experimentan mejoras continuas y son elementos reutilizables. 
• Los patrones hablan de diseño y buenas prácticas y se pueden usar varios a la vez para resolver grandes problemas. 

Al igual que otras disciplinas y ciencias, la ingeniería de software depende en gran parte del uso de patrones de diseño para garantizar rendimiento de los sistemas y eficiencia en el ciclo de desarrollo. Una de las metas de un arquitecto de software o desarrollador es saber abordar los problemas con las mejores herramientas de diseño y para esto es importante conocer los patrones y las técnicas.



CLASIFICACIÓN DE LOS PATRONES 


Patrones de creación


Abstraen la forma en la que se crean los objetos, permitiendo tratar las clases a crear de forma genérica, dejando para más tarde la decisión de qué clases crear o cómo crearlas.Prototype, Singleton, Factory Method, Abstract Factory,...)

Patrones estructurales

Se ocupan de cómo se utilizan clases y objetos para componer estructuras de mayor tamañoLo fundamental son las relaciones de uso entre los objetos, y, éstas están determinadas por las interfaces que soportan los objetos. 

Estudian cómo se relacionan los objetos en tiempo de ejecución y sirven para diseñar las interconexiones entre los objetos.(Composite, Proxy, Facade, Decorator, ...)



Patrones de comportamiento

Se refieren a los algoritmos y a la asignación de responsabilidades entre objetos.

Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos, normalmente ligados con la dimensión temporal.

(Chain of Responsability, State, Strategy, Visitor, Observer, Template Method, Memento,...)