Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus

relaciones) con las que construir sistemas de software

Los patrones de diseo son la base para la bsqueda de soluciones a problemas comunes en el
desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces.
Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea
considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que
debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en
distintas circunstancias.

Definicin de Persistencia de objetos
Se entiende por persistencia la accin de preservar la informacin de un objeto de forma
permanente (guardar), pero a su vez tambin se refiere a poder recuperar la informacin del
mismo (leer) para que pueda ser nuevamente utilizada.

Patrn de Diseo: Data Access Object (DAO) + Data Transfer Object (DTO)

Los Objetos de Acceso a Datos son un Patrn de los subordinados de Diseo Core J2EE y
considerados una buena prctica. La ventaja de usar objetos de acceso a datos es que
cualquier objeto de negocio (aquel que contiene detalles especficos de operacin o aplicacin) no
requiere conocimiento directo del destino final de la informacin que manipula.
Los Objetos de Acceso a Datos pueden usarse en Java para aislar a una aplicacin de la tecnologa
de persistencia Java subyacente (API de Persistencia Java), la cual podra ser JDBC, JDO, Enterprise
JavaBeans, TopLink, EclipseLink, Hibernate, iBATIS, o cualquier otra tecnologa de persistencia.
Usando Objetos de Acceso de Datos significa que la tecnologa subyacente puede ser actualizada o
cambiada sin cambiar otras partes de la aplicacin.
La flexibilidad tiene un precio. Cuando se aaden DAOs a una aplicacin, la complejidad adicional
de usar otra capa de persistencia incrementa la cantidad de cdigo ejecutado durante tiempo de
ejecucin. La configuracin de las capas de persistencia requiere en la mayora de los casos mucho
trabajo.
Las aplicaciones crticas con el rendimiento no deberan usar DAOs


DAO es que nos provee de una forma totalmente abstracta de acceso a datos
En software de computadores, un Data Access Object (DAO, Objeto de Acceso a Datos) es un
componente de software que suministra una interfaz comn entre la aplicacin y uno o ms
dispositivos de almacenamiento de datos, tales como una Base de datos o un archivo. El trmino
se aplica frecuentemente al Patrn de diseo Object.


Abstraccin puede referirse a:
Abstraccin (informtica), aislar un elemento de su contexto o del resto de los elementos que lo
acompaan.
Abstraccin (filosofa), acto mental en el que conceptualmente se asla un objeto o una propiedad
de un objeto.
Abstraccin (psicologa), proceso que implica reducir los componentes fundamentales de
informacin de un fenmeno para conservar sus rasgos ms relevantes.

Capa de abstraccin, manera de ocultar los detalles de implementacin de ciertas funcionalidades.
Inversin de abstraccin, anti patrn que tiene lugar cuando una interfaz no expone las
funcionalidades requeridas por los usuarios.
Una capa de abstraccin (o nivel de abstraccin) es una forma de ocultar los detalles de
implementacin de ciertas funcionalidades

Soporte DAO (Data Access Object) y JDBC

El paquete DAO provee una capa de abstraccin de JDBC, el patrn DAO es uno de los ms
comnmente utilizados en aplicaciones J2EE, y la arquitectura de acceso a datos de Spring
proporciona un sofisticado pero an sencillo soporte la misma.

Los DAO son un patrn de diseo J2EE y considerados una buena prctica. La ventaja de usar
objetos de acceso a datos es que cualquier objeto de negocio (el cual contiene detalles especficos
de operacin o aplicacin) no requiere conocimiento directo del destino final de la informacin
que manipula.
Los DAO pueden usarse en Java para aislar a una aplicacin de la tecnologa de persistencia Java
subyacente (API de Persistencia Java), la cual podra ser JDBC, JDO, EJB CMP (Persistencia
controlada por el Contenedor), TopLink, Hibernate, iBATIS, o cualquier otra tecnologa de
persistencia. Usando DAO significa que la tecnologa subyacente puede ser actualizada o cambiada
sin cambiar otras partes de la aplicacin.

JDBC es el acrnimo de Java Database Connectivity, un API que permite la ejecucin de
operaciones sobre bases de datos desde el lenguaje de programacin Java independientemente
del sistema de operacin donde se ejecute o de la base de datos a la cual se accede utilizando el
dialecto SQL del modelo de base de datos que se utilice.
El API JDBC se presenta como una coleccin de interfaces Java y mtodos de gestin de
manejadores de conexin hacia cada modelo especfico de base de datos. Un manejador de
conexiones hacia un modelo de base de datos en particular es un conjunto de clases que
implementan las interfaces Java y que utilizan los mtodos de registro para declarar los tipos de
localizadores a base de datos (URL) que pueden manejar. Para utilizar una base de datos
particular, el usuario ejecuta su programa junto con la librera de conexin apropiada al modelo de
su base de datos, y accede a ella estableciendo una conexin, para ello provee en localizador a la
base de datos y los parmetros de conexin especficos. A partir de all puede realizar con
cualquier tipo de tareas con la base de datos a las que tenga permiso: consultas, actualizaciones,
creado modificado y borrado de tablas, ejecucin de procedimientos almacenados en la base de
datos, etc.
JDBC cumple su objetivo mediante un conjunto de interfaces de java, cada una implementada de
manera diferente por distintos distribuidores. El conjunto de clases que la componen se denomina
el controlador JDBC.

Spring JDBC framework se construye sobre el ncleo de la API JDBC de J2SE, y es la tecnologa de
acceso a datos de ms bajo nivel que Spring soporta. Otras tecnologas de alto nivel son iBATIS SQL
Maps, Hibernate, JDO.

Objeto de transferencia de datos (DTO) es un objeto que lleva datos entre procesos. La motivacin
para el uso que tiene que ver con el hecho de que la comunicacin entre procesos se realiza por lo
general recurrir a interfaces remotas (por ejemplo, servicios web), donde cada llamada es una
operacin costosa. Debido a que la mayor parte del coste de cada llamada es relacionada para el
tiempo de ida y vuelta entre el cliente y el servidor, una forma de reducir el nmero de llamadas
es utilizar un objeto (DTO) que agrega los datos que le han sido transferidos por las varias
llamadas, pero que es servida por uno llamar solamente.
La diferencia entre los objetos de transferencia de datos y objetos de negocio o los objetos de
acceso a datos es que una organizacin de narcotrfico no tiene ningn comportamiento, excepto
para el almacenamiento y la recuperacin de sus propios datos (descriptores de acceso y
mutators). DTO son objetos simples que no debe contener ninguna lgica de negocio que
requerira pruebas.
Este patrn se utiliza a menudo de forma incorrecta fuera de las interfaces remotas. Esto ha
provocado una respuesta por parte de su autor en el que reitera que todo el propsito de OTD es
cambiar los datos en llamadas remotas caros.

El chiste del DAO es que nos provee de una forma totalmente abstracta de acceso a datos. Es
decir, puedo acceder a mi modelo de datos, pero irnicamente a travs del conjunto de mtodos
que me brinda un DAO. Si tengo un DAO para coches, por ejemplo CocheDAO, en l deber tener
definido por ejemplo un mtodo Count() que me retornar el total de coches que tengo en mi
base de datos. No s cmo est implementado, ni qu base de datos utiliza (si es que accede a una
base de datos), lo nico que s es que resuelve mi problema.

Por lo tanto, desde la parte del Controlador de mi aplicacin, puedo acceder a mi Modelo
utilizando el patrn de diseo que ofrece DAO, de forma totalmente transparente. Esto por
ejemplo nos llevar-a a pensar que nuestro CocheDAO podr-a contener otros mtodos, como el
mtodo Delete (que borrar-a un coche de la base de datos), Update (que actualizar-a los datos de
un coche), GetCochesByMarca (que a partir de una marcha retornar-a los coches de la marca que
hay en la base de datos), etc.

Todo esto suena en principio a lo mismo que ser-a tener una clase llamada Coche llena de
mtodos static a los cuales llamar-a cuando fuera necesario. Esto, pues claro, resuelve el
problema de tener todo el acceso a la tabla Coche centralizado, ol, bien, somos ordenados, pero
DAO va mucho ms all. Cmo resolver-ais el problema de devolver un listado de coches a travs
de vuestra clase con mtodos static? Pues a lo mejor vuestro mtodo GetCoches() retorna un
dataset rellenado con los coches, o un datareader/recordset, o una lista separada por comas, o
una estructura xml, o un array Pero los DAO incluyen otro concepto que es de los DTO.
Los DTO son un tipo de objetos que sirven nicamente para transportar datos. Por ejemplo, el
objeto de transferencia de datos de un coche podr-a ser un CocheDTO (o CocheBean para los
javeros). Entonces, DAO, lo que devuelve es una lista genrica de CocheBean, o tal vez un
CocheBean si estamos buscando informacin de un solo coche. Para que os hagis una idea, un
CocheBean contiene nicamente propiedades de un coche como por ejemplo Marca,
NumeroPuertas, Matr-cula, etc. El DAO, tras una peticin del Controlador, rellena un DTO o un
conjunto de ellos, y lo devuelve al Controlador.

Y todo este lo para qu? Pues muy sencillo, si vuestro controlador ataca al modelo utilizando
DAO y DTO estis consiguiendo 100% la separacin entre el Controlador y el Modelo. Ante
cualquier cambio que se diera en la forma de acceder a los datos, pongamos por ejemplo que a
partir de ahora en lugar de sacar los coches de una tabla coches se hace de un servicio web que
retorna coches, vuestro modelo no se va a enterar, ya que lo que le va a seguir llegando van a ser
siempre CocheBean. Consegu-s un impacto cero patatero en vuestro Controlador (y en la Vista
claro, pero eso ya lo hab-amos conseguido separando la Vista del Controlador).

Y an ms, si cada uno de vuestros DAO lo preparis para seguir el patrn Singleton, tendris
siempre una nica instancia de la clase CocheDAO en memoria, por lo que aunque tengis 200
usuarios tirando de dicho DAO tendris una nica copia en memoria, con el ahorro que esto
supone. Esto no ocurre por ejemplo si usis static en todos los mtodos de vuestras clases de
acceso a datos (y os recuerdo que en un proyecto mediano el nmero de mtodos que llegan a
acumularse para acceso a datos suele ser bastante grande).










Un ejemplo de cdigo? Venga, vale, aceptamos barco, imaginaos que atacamos a una hipottica
clase CocheDAO:

// GetInstance pide la instancia de la clase mediante el Singleton, CocheDAO tiene su constructor
en modo privado.
CocheBean coche = CocheDAO.GetInstance().GetCocheByMatricula(IB-3234-ZX);
// ahora tenemos un CocheBean, si no es nulo es que ha llegado bien, cogemos sus datos
if (coche != null)
{
txtMatricula.Text = coche.Matricula;
txtMarca.Text = coche.Marca;
txtNumeroPuertas.Text = coche.NumeroPuertas;
}

Y qu ocurre en el Controlador si cambiamos el nombre del campo matr-cula en la tabla coches?
Pues nada, ni se entera.

Para finalizar os aado un link a un rar que he preparado con un DAO y un DTO preparados, que
acceden a una hipottica tabla de Coches. Fijaros en el DAO lo que hace el Singleton, que adems
de forzar la utilizacin del mtodo GetInstance, utiliza exclusin mtua para evitar que se tenga
ms de una instancia del DAO en el caso de no haberse creado an la instancia y dos usuarios
accedieran al mismo tiempo al mtodo GetInstance. El mtodo GetCoche retorna un CocheBean,
pero el mtodo GetCoches lo que hace es retornar un lista genrica de CocheBean. Veris adems
que CocheDAO hereda de BaseDAO, todos los DAOS deber-an heredar de all- ya que BaseDAO les
ofrece entre otras cosas la conexin a la base de datos y una serie de mtodos comunes que
pueden utilizar (BaseDAO lo he dejado algo bsico slo para que se entienda conceptualmente
qu es lo que se supone que debe hacer). Tambin tenis la definicin de CocheBean. Por ltimo,
veris que existe un archivo llamado Excepciones donde se tipifican las excepciones que puede
generar un DAO, una de las buenas prcticas de las que ya hemos hablado en otros art-culos.
Os contar-a adems que DAO puede implementarse junto a DTO, pero adems utilizando el
modelo de Factora, pero esto, lo dejaremos para ms adelante.