Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus
relaciones) con las que construir sistemas de software Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas car acterísticas. 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 diseño en distintas circunstancias. Definición de Persistencia de objetos Se entiende por persistencia la acc ión de preservar la información de un objeto de forma permanente (guardar), pero a su vez también se refiere a poder recuperar r ecuperar la información del mismo (leer) para que pueda ser nuevamente utilizada. Patrón de Diseño: Data Access Object (DAO) + Data Transfer Object (DTO)
Los Objetos de Acceso a Datos D atos son un Patrón de los subordinados de Diseño Core J2EE y considerados una buena práctica. La ventaja de usar objeto s de acceso a datos es que cualquier objeto de negocio (aquel que contiene det alles específicos de operación o aplicación) no requiere conocimiento directo del destino final de la información que manipula. Los Objetos de Acceso a Datos D atos pueden usarse en Java para aislar a una aplicación de la tecnología de persistencia Java subyacente (API de Persistencia Java), la cual podría ser JDBC, JDO, Enterprise JavaBeans, TopLink, EclipseLink, Hibernate, iBATIS, o cualquier otra tecnología de per sistencia. Usando Objetos de Acceso de Datos significa que la tecnología subyacente puede ser actualizada o cambiada sin cambiar otras partes de la aplicación. La flexibilidad tiene un precio. Cuando se añaden DAOs a una aplicación, la complejidad adicional de usar otra capa de persistencia incrementa la cantidad de código ejecutado durante t iempo 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 deberían usar DA Os
DAO es que nos provee de una forma totalmente abstracta de acceso a datos En software de software de computadores, un Data Access Object (DAO, Objeto de Acceso a Datos) es un componente de software que suministra una interfaz común interfaz común entre la aplicación y uno o más
dispositivos de almacenamiento de datos, tales como una Base de datos o un archivo. El término se aplica frecuentemente al Patrón de diseño Object.
Abstracción puede referirse a: Abstracción (informática), aislar un elemento de su contexto o del resto de los elementos que lo acompañan. Abstracción (filosofía), acto mental en el que conceptualmente se aísla un objeto o una propiedad de un objeto. Abstracción (psicología), proceso que implica reducir los componentes fundamentales de información de un fenómeno para conservar sus rasgos más relevantes. Capa de abstracción, manera de ocultar los detalles de implementación de ciertas funcionalidades. Inversión de abstracción, anti patrón que tiene lugar cuando una interfaz no expone las funcionalidades requeridas por los usuarios. Una capa de abstracción (o nivel de abstracción) es una forma de ocultar los detalles de implementación de ciertas funcionalidades Soporte DAO (Data Access Object) y JDBC
El paquete DAO provee una capa de abstracción de JDBC, el patrón DAO es uno de los más comúnmente utilizados en aplicaciones J2EE, y la arquitectura de acceso a datos de Spring proporciona un sofisticado pero aún sencillo soporte la misma. Los DAO son un patrón de diseño J2EE y considerados una buena práctica. La ventaja de usar objetos de acceso a datos es que cualquier objeto de negocio (el cual contiene detalles específicos de operación o aplicación) no requiere conocimiento directo del destino final de la información que manipula. Los DAO pueden usarse en Java para aislar a una aplicación de la tecnología de persistencia Java subyacente (API de Persistencia Java), la cual podría ser JDBC, JDO, EJB CMP (Persistencia controlada por el Contenedor), TopLink, Hibernate, iBATIS, o cualquier otra tecnología de persistencia. Usando DAO significa que la tec nología subyacente puede ser actualizada o cambiada sin cambiar otras partes de la aplicación. JDBC es el acrónimo de Java Database Connectivity, un API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java independientemente del sistema de operación 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 colección de interfaces Java y métodos de gestión de manejadores de conexión hacia cada modelo específico 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 métodos 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 pro grama junto con la librería de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión, para ello provee en localizador a la base de datos y los parámetros de conexión específicos. 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, ejecución 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 núcleo de la API JDBC de J2SE, y es la tecnología de acceso a datos de más bajo nivel que Spring soporta. Otras tecnologías de alto nivel son iBATIS SQL Maps, Hibernate, JDO.
Objeto de transferencia de datos (DTO) es un objeto que lleva datos entre procesos. La motivación para el uso que tiene que ver con el hecho de que la comunicación entre procesos se realiza por lo general recurrir a interfaces remotas (por ejemplo, servicios web), donde cada llamada es una operación 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 número 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 organización de narcotráfico no tiene ningún comportamiento, excepto para el almacenamiento y la recuperación de sus propios datos (descriptores de acceso y mutators). DTO son objetos simples que no debe contener ninguna lógica de negocio que requeriría pruebas. Este patrón se utiliza a menudo de forma incorre cta fuera de las interfaces remotas. Esto ha provocado una respuesta por parte de su autor en el que reitera que todo el propósito 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 irónicamente a través del conjunto de métodos que me brinda un DAO. Si tengo un DAO para coches, por ejemplo CocheDAO, en él deberé tener definido por ejemplo un método Count() que me retornará el total de coches que tengo en mi base de datos. No sé cómo está implementado, ni qué base de datos utiliza (si es que accede a una base de datos), lo único que sé e s que resuelve mi problema.
Por lo tanto, desde la parte del Controlador de mi aplicación, puedo acceder a mi Modelo utilizando el patrón de diseño que ofrece DAO, de forma totalmente transparente. Esto por ejemplo nos llevaría a pensar que nuestro CocheDAO podría contener otros métodos, como el método 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 métodos static a los cuales llamaría cuando fuera necesario. Esto, pues c laro, resuelve el problema de tener todo el acceso a la tabla Coche centralizado, olé , bien, somos ordenados, pero DAO va mucho más allá. ¿Cómo resolveríais el problema de devolver un listado de coches a través de vuestra clase con métodos static? Pues a lo mejor vuestro método 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 D AO 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 genérica de CocheBean, o tal vez un CocheBean si estamos buscando información de un solo coche. Para que os hagáis una idea, un CocheBean contiene únicamente propiedades de un coche como por ejemplo Marca, NumeroPuertas, Matrícula, etc. El DAO, tras una petición del Controlador, rellena un DTO o un conjunto de ellos, y lo devuelve al Controlador.
¿Y todo este lío para qué? Pues muy sencillo, si vuestro controlador ataca al modelo utilizando DAO y DTO estáis consiguiendo 100% la separación 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 e n vuestro Controlador (y en la Vista claro, pero eso ya lo habíamos conseguido separando la Vista del Contr olador).
Y aún más, si cada uno de vuestros D AO lo preparáis para seguir el patrón Singleton, tendréis siempre una única instancia de la clase CocheDAO e n memoria, por lo que aunque tengáis 200 usuarios tirando de dicho DAO tendréis una única copia en memoria, con el ahorro que esto supone. Esto no ocurre por ejemplo si usáis static e n todos los métodos de vuestras clases de acceso a datos (y os recuerdo que en un proyecto mediano el número de métodos que llegan a acumularse para acceso a datos suele ser bastante grande).
¿Un ejemplo de código? Venga, vale, ace ptamos barco, imaginaos que atacamos a una hipotética 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 añado un link a un rar que he preparado con un DAO y un D TO preparados, que acceden a una hipotética tabla de Coches. Fijaros en el DAO lo que hace el Singleton, que además de forzar la utilización del método GetInstance, utiliza exclusión míºtua para evitar que se tenga más de una instancia del DAO en el caso de no haberse creado aíºn la instancia y dos usuarios accedieran al mismo tiempo al método GetInstance. El método GetCoche retorna un CocheBean, pero el método GetCoches lo que hace es retornar un lista genérica de CocheBean. Veréis además que CocheDAO hereda de BaseDAO, todos los DAOS deberían heredar de allí ya que BaseDAO le s ofrece entre otras cosas la conexión a la base de datos y una serie de métodos comunes que pueden utilizar (BaseDAO lo he dejado algo básico sólo para que se entienda conceptualmente qué es lo que se supone que debe hacer). También tenéis la definición de CocheBean. Por íºltimo, veréis que existe un archivo llamado Excepciones donde se tipifican las excepciones que puede generar un DAO, una de las buenas prácticas de las que ya hemos hablado en otros artículos. Os contaría además que DAO puede implementarse junto a D TO, pero además utilizando el modelo de Factoría, pero esto, lo dejaremos para más adelante.
