PATRÓN VALUE LIST HANDLER

CONTEXTO

El cliente le pide al servicio una lista de ítems para su presentación. El número de ítems de la lista no se conoce y puede ser muy grande en muchas circunstancias.

PROBLEMA

La mayoría de las aplicaciones de la plataforma J2EE tienen un requerimiento de búsqueda y consulta para buscar y listar ciertos datos. En algunos casos, dichas operaciones de búsqueda y consulta podrían traer resultados que pueden ser bastante grandes. No es práctico devolver toda la hoja de resultados cuando los requerimientos del cliente son moverse por los resultados, en vez de procesar el conjunto completo. Normalmente, un cliente usa los resultados de una consulta para propósitos de sólo-lectura, como mostrar una lista de resultados. Muchas veces el cliente sólo ve los primeros registros que devuelve la búsqueda, y podría descargar los registros restantes e intentar otra nueva consulta. La práctica de obtener uns lista de valores representados en un bean de entidad llamando al método ejbFind(), que devuelve una collection de objetos remotos, y luego llamar a cada bean de entidad para obtener el valor, consume muchos recursos de red y se considera una mala práctica.

Hay algunas consecuencias asociadas con el uso de los métodos búscadores de EJB que resultan en grandes conjuntos de datos. Cada implementación de contenedor tiene una cierta cantidad de métodos búscadores para crear una colección de referencias EJBObject. El rendimiento del método de búsqueda varía, dependiendo de la implementación del contenedor. De acuerdo a la especificación EJB, un contenedor podría invocar a métodos ejbActivate() sobre entidades encontradas con los métodos de búsqueda. Como mínimo, un método de búsqueda devuelve las claves primarias de las entidades encontradas, que el contenedor devuelve al cliente como una colección de referencias EJBObject. Este comportamiento se aplica para todas las implementaciones de contenedores. Algunas implementaciones podrían introducir una sobrecarga de métodos de búsqueda asociando los ejemplares de beans de entidad a esos ejemplares EJBObject para darle acceso al cliente a esos beans de entidad. Sin embargo, este es un uso pobre de los recursos si el cliente no está interesado en acceder al bean o en invocar sus métodos. Esta sobrecarga puede impedir el rendimiento de la aplicación si ésta incluye consultas que producen muchos resultados.

CAUSAS

• La aplicación cliente necesita una facilidad de consulta eficiente para evitar tener que llamar al método ejbFind() de cada bean e invocar a cada objeto remoto devuelto.
• Se necesita una mecanismo de caché en la capa-servidor para servir a los clientes que no pueden recibir y procesar el cojunto de resultados completo.
• Se puede optimizar una consulta que se ejecuta repetidamente sobre unos datos razonablemente estáticos para proporcionar resultados más rápidos. 
• Los métodos de búsqueda EJB no son apropiados para navegar por tablas enteras en la bases de datos o para buscar grandes conjuntos de resultados en una tabla.
• Los métodos de búsqueda se podrían considerar sobrecargados cuando se utilizan para encontrar grandes cantidades de resultados. 
• Los métodos de búsqueda EJB no sin apropiados para realizar caché de resultados. El cliente podría no ser capaz de manejar el conjunto completo de resultados en una sóla llamada. 
• Los métodos de búsqueda EJB tiene consultas predeterminadas y ofrecen una flexibilidad mínima. 
• El cliente quiere moverse hacia adelante o hacia atrás dentro de la hoja de resultados.

SOLUCIÓN

Utilizar un Value List Handler para controlar la búsqueda, hacer un caché con los resultados, y proporcionar los resultados al cliente en una hoja de resultados cuyo tamaño y desplazamiento cumpla los requerimientos del cliente.

Este patrón crea un ValueListHandler para controlar la funcionalidad de la ejecución de la consulta y el caché de resultados. El ValueListHandler accede directamente a un DAO que puede ejecutar la consulta requerida. El ValueListHandler almacena los resultados obtenidos del DAO como una colección de Transfer Objects. El cliente le pide al ValueListHandler que proporcione resultados de la consulta según los necesite. El ValueListHandler implementa un patrón Iterator [GoF] para proporcionar la solución.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases para el patrón Value List Handler:

PARTICIPANTES Y COLABORACIONES
La siguiente figura muestra el diagrama de secuencia del patrón Value List Handler:

ValueListIterator- Este interface podría proporcionar la facilidad de iteración con los siguientes métodos de ejemplo:

• getSize() obtiene el tamaño de la hoja de resultados.
• getCurrentElement() obtiene el Transfer Object actual de la lista.
• getPreviousElements(int howMany) obtiene una colección de Transfer Objects que son anteriores en la lista al elemento actual.
• getNextElements(int howMany) obtiene una colección de Transfer Objects que son posteriores en la lista al elemento actual.
• resetIndex() reinicia el índice para ir al inicio de la lista.

Dependiendo de las necesidades, se pueden incluir otros métodos de conveniencia en el interface ValueListIterator.

ValueListHandler- Este es el objeto que implementa el interface ValueListIterator. ValueListHandler ejecuta la consulta requerida cuando se lo solicita el cliente. Obtiene los resultados de la consulta, que maneja en una colección privada representada por el objeto ValueList. ValueListHandler crea y manipula la colección ValueList.

DataAccessObject- ValueListHandler puede hacer uso de un DataAccessObject para mantener separada la implementación del acceso a la base de datos. DataAccessObject proporciona un API sencillo para acceder a la base de datos (o cualquier otro almacenamiento persistente), ejecuta consultas y recupera resultados.

ValueList- ValueList es una colección (una lista) que contiene los resultados de la consulta. Los resultados se almacenan como objetos Transfer Objects. Si falla la consulta y no se devuelven resultados, entonces esta lista está vacía. El bean de sesión ValueListHandler puede almacenar ValueList para evitar repeticiones innecesarias de la consulta.

TransferObject- TransferObject representa una vista de un registro individual de los resultados de la consulta. Es un objeto serializable no modificable que proporciona un espacio para los datos de los atributos de cada registro.

CONSECUENCIAS

• Proporciona Alternativas a los métodos find() de EJB para Grandes Consultas 
• Crea un Caché de Resultados de la Consulta en el Lado del Servidor 
• Proporciona una Mayor Flexibilidad de Consulta 
• Mejora el Rendimiento de Red 
• Permite Atrasar las Transacciones del Bean de Entidad