PATRÓN VIEW HANDLER

CONTEXTO

Un sistema de software que provee vistas múltiples de aplicaciones de datos específicos, o que soporta el trabajo con múltiples documentos.

PROBLEMA

Los sistemas de software que soportan vistas múltiples necesitan  funcionalidad adicional para su manejo. Los usuarios desean poder abrir, manipular y disponer de vistas como ventanas y otros contenidos a su conveniencia. Las vistas deben ser coordinadas, para que la actualización de una de ellas sea propagada automáticamente a las vistas de relación.  Distintas fuerzas manejan la solución a este problema:

El manejo de vistas múltiples debe ser fácil desde la perspectiva del usuario, y también para los componentes del cliente sin el sistema.

Las implementaciones de vistas individuales no deben depender las unas de las otras o ser mezcladas con el código usado para el manejo de vistas.

La implementación de las vistas puede variar y tipos adicionales de vistas pueden ser agregados durante el tiempo de vida del sistema.

SOLUCIÓN

Un componente VH maneja todas las vistas que el sistema de software provee. Ofrece la funcionalidad necesaria para abrir, coordinar y cerrar vistas específicas, también para manejarlas; un comando para “tile” las vistas, esto es ordenarlas en un patrón ordenado.

ESTRUCTURA

El VH es el componente central de este patrón. Es responsable de abrir vistas nuevas y los clientes pueden especificar la vista que desean. El VH inicia instantáneamente los correspondientes componentes de vista, cuida su correcta inicialización y pide a la nueva vista que se despliegue.

También ofrece funciones para cerrar vistas, individualmente abiertas, tal como se necesitan al cerrar la aplicación. La principal responsabilidad del VH es, sin embargo ofrecer servicios de manejo de vistas. Una responsabilidad adicional del VH es la coordinación.

Un componente de vista abstracto define una interfaz que es común para todas las vistas. El VH usa esta interfaz para crear, coordinar y cerrar vistas. La plataforma subyacente al sistema usa la interfaz para ejecutar eventos de usuario; el cambio de tamaño de una ventana. La interfaz de la vista abstracta debe ofrecer una función correspondiente para todas las operaciones posibles que se pueden ejecutar en una vista.
Los componentes de vista específicos se derivan de la vista abstracta e implementan su interfaz además, cada vista implementa su propia función de desplegado.

Creación de una vista nueva

Organiza el apilamiento de vistas

CONSECUENCIAS

Beneficios

• Manejo uniforme de las vistas.
• Extensibilidad y cambiabilidad de las vistas.
• Coordinación de vistas de aplicación especifica.

El patrón VH tiene desventajas

• Aplicabilidad restringida.
• Eficiencia.

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 

PATRÓN TRANSFER OBJECT

CONTEXTO

Las aplicaciones cliente necesitan intercambiar datos con Beans Enterprise.

PROBLEMA

Las aplicaciones de la plataforma J2EE implementan componentes de negocio del lado del servidor como beans de sesión y de entidad. Algunos métodos expuestos por los componentes de negocio devuelven datos al cliente. Algunas veces, el cliente invoca a los métodos get de un objeto de negocio varias veces para obtener todos los valores de los atributos.

Los beans de sesión representan los servicios de negocio y no se comparten entre usuarios. Un bean de sesión proporciona métodos de servicios genéricos cuando se implementan para el patrón Session Facade.

Por otro lado, los beans de entidad, son objetos transaccionales, multiusuario que representan datos persistentes. Un bean de entidad expone los valores de los atributos proporcionando un método accesor (también referidos como métodos get) por cada atributo que desea exponer.

CAUSAS

• Todos los accesos a un bean enterprise se realizan mediante interfaces remotos. 
• Normalmente, las aplicaciones tienen transacciones de lectura con mayor frecuencia que las de actualización. 
• El cliente normalmente solicita valores que son algo más que un atributo o que son dependientes del objeto de un bean enterprise. 
• El número de llamadas que un cliente hace al bean enterprise impactan en el rendimiento de la red. 

SOLUCIÓN

Utilizar un Transfer Object para encapsular los datos de negocio. Se utiliza una única llamada a un método para envíar y recuperar el Transfer Object. Cuando el cliente solicita los datos de negocio al bean enterprise, éste puede construir el Transfer Object, rellenarlo con sus valores de atributos y pasarlo por valor al cliente.

Los clientes normalmente solicitan más de un valor a un bean enterprise. Para reducir el número de llamadas remotas y evitar la sobrecarga asociada, es mejor el Transfer Objects para transportar los datos desde el bean enteprise al cliente.

Cuando un bean enterprise utiliza un Transfer Object, el cliente hace una sola llamada a un método remoto del bean enterprise para solicitar el Transfer Object en vez de numerosas llamadas remotas para obtener valores de atributos individuales. Entonces el bean enterprise construye un nuevo ejemplar Transfer Object, copia dentro los valores del objeto y lo devuelve al cliente. El cliente recibe el Transfer Object y puede entonces invocar los métodos accesores (o get) del Transfer Object para obtener los valores de atributos individuales del objeto Transfer Object.

ESTRUCTURA
La siguiente figura muestra el diagrama de clases que representa el patrón Transfer Object en su forma más simple:

Como se ve en este diagrama de clases, el Transfer Object lo construye bajo pedido el bean enterprise y lo devuelve al cliente remoto. Sin embargo, el patrón Transfer Object puede adoptar varias estrategias, dependiendo de los requerimientos.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura contiene el diagrama de secuencia que muestra las interacciones del patrón Transfer Object:

 

Client- Representa al cliente del bean enterprise. El cliente puede ser una aplicación final de usuario, como es el caso de una aplicación que ha sido diseñada para acceder directamente a beans enterprise. El cliente puede utilizar Business Delegate u otro BusinessObject diferente.

BusinessObject- Representa un rol en este patrón que puede cumplir un bean de sesión, un bean de entidad, o un Data Access Object (DAO). BusinessObject es el responsable de crear el Transfer Object y devolverlo al cliente bajo pedido. El BusinessObject también podría recibir datos desde el cliente en la forma de un Transfer Object y utilizar esos datos para realizar una actualización.

TransferObject- TransferObject es un objeto Java serializable referenciado como un Transfer Object. Una clase Transfer Object podría proporcionar un constructor que acepte todos los atributos requeridos para crear el Transfer Object.

CONSECUENCIAS

• Simplifica el Bean de Entidad y el Interface Remoto 
• Transfiere Más Datos en Menos Llamadas Remotas 
• Reduce el Tráfico de Red 
• Reduce la Duplicación de Código
• Podría Introducir Transfer Objects Obsoletos 
• Podría Incrementar la Complejidad Debido a la Sincronización y el Control de Versión 
• Accesos y Transacciones Concurrentes 

PATRÓN SERVICE LOCATOR

CONTEXTO

La búsqueda y creación de servicios implican interfaces complejos y operaciones de red.

PROBLEMA

Los clientes J2EE interactúan con componentes de servicio, como componentes JavaBeans Enterprise (EJB) y Java Message Service (JMS), que proporcionan servicios de negocio y capacidades de persistencia. Para interactúar con estos componentes, los clientes deben o lcalizar el componente de servicio (referido como una operación de búsqueda) o crear un nuevo componente. Por ejemplo, un cliente EJB debe localizar el objeto home del bean enterprise, que el cliente puede utilizar para encontrar un objeto o para crear uno o más beans enterprise. De forma similar, un cliente JMS primero debe localizar la Factoría de Conexiones JMS para obtener una Conexión JMS o una Sesión JMS.

Todos los clientes de aplicaciones J2EE utilizan la facilidad JNDI para buscar y crear componentes EJB o JMS. El API JNDI permite a los clientes obtener un objeto Contexto Inicial que contiene el nombre del componente a uniones de objetos. El cliente empieza obteniendo el contexto inicial para un objeto home de un bean. El contexto inicial permanece válido mientras sea válida la sesión del cliente. El cliente proporciona el nombre registrado en JNDI del objeto requerido para obtener una referencia a un objeto administrado. En el contexto de una aplicación EJB, un objeto administrado típico es un objeto home de un bean enterprise. Para aplicaciones JMS, el objeto administrado puede ser una Factoría de Conexiones JMS (para un Topic o una Queue) o un Destino JMS (un Topic o una Queue).

CAUSAS

• Los clientes EJB necesitan utilizar el API JNDI para buscar objetos EJBHome utilizando el nombre registrado del bean enterprise.
• Los clientes JMS necesitan utilizar el API JNDI para buscar componentes JMS utilizando los nombres registrados en JDNI para esos componentes JMS.
• La factoría de contextos utilizada para la creación del contexto inicial JNDI la proporciona el vendedor del proveedor del servicio y por lo tanto es dependiente del vendedor. 
• La búsqueda y creación de componentes de servicio podría ser compleja y se podría utilizar repetidamente en múltiples clientes en la aplicación.
• La creación del contexto inicial y el servicio de búsqueda de objetos, si se utiliza frecuentemente, puede consumir muchos recursos e impactar en el rendimiento de la aplicación. 
• Los clientes EJB podrían necesitar reestablecer conexiones a un ejemplar de bean enterprise al que se ha accedido préviamente, teniendo solamente su objeto Handle.

SOLUCIÓN

Utilizar un objeto Service Locator para abstraer toda la utilización JNDI y para ocultar las complejidades de la creación del contexto inicial, de busqueda de objetos home EJB y de re-creación de objetos EJB. Varios clientes pueden reutilizar el objeto Service Locator para reducir la complejidad del código, proporcionando un punto de control, y mejorando el rendimiento proporcionando facilidades de caché.

Este patrón reduce la complejidad del cliente que resulta de las dependencias del cliente y de la necesidad de realizar los procesos de búsqueda y creación, que consumen muchos recursos. Para eliminar estos problemas, este patrón proporciona un mecanismo para abstraer todas las dependencias y detalles de red dentro del Service Locator.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases que representa las relaciones para el patrón Service Locator.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura contiene el diagrama de secuencia que muestra la interacción entre los distintos participantes en el patrón Service Locator.

Client- Este es el cliente del Service Locator. El cliente es un objeto que normalmente requiere acceder a objetos de negocio como un Business Delegate.

Service Locator- El Service Locator abstrae el API de los servicios de búsqueda (nombrado), las dependencias del vendedor, las complejidades de la búsqueda, y la creación de objetos de negocio, y proporciona un interface simple para los clientes. Esto reduce la complejidad del cliente. Además, el mismo cliente y otros clientes pueden reutilizar el Service Locator.

InitialContext- El objeto InitialContext es el punto de inicio para los procesos de búsqueda y creación. Los proveedores de servicio proporcionan el objeto context, que varía dependiendeo del tipo de objetos de negocio proporcionados por el servicio de búsqueda y creación del Service Locator.

ServiceFactory- El objeto ServiceFactory representa un objeto que proporciona control del ciclo de vida para objetos BusinessService. El objeto ServiceFactory para beans enterprise es un objeto EJBHome. El ServiceFactory para componentes JMS puede ser un objeto ConnectionFactory, como un TopicConnectionFactory o un QueueConnectionFactory.

BusinessService- BusinessService es un rol que cumple el servicio que el cliente ha solicitado. El objeto BusinessService se crea, se busca o se elimina mediante el objeto ServiceFactory. El objeto BusinessService en el contexto de una aplicación EJB es un bean enterprise. El objeto BusinessService en el contexto de una aplicación JMS puede ser un TopicConnection o un QueueConnection. TopicConnection y QueueConnection se pueden entonces utilizar para producir un objeto JMSSession, como un TopicSession o un QueueSession respectivamente.

CONSECUENCIAS

• Abstrae la Complejidad 
• Proporciona a los Clientes un Acceso Uniforme a los Servicios 
• Facilita la Adicción de Nuevos Componentes de Negocio 
• Mejora el Rendimiento de la Red 
• Mejora el Rendimiento del Cliente mediante el Caché 

PATRÓN SESSION FACADE

CONTEXTO

Los Beans Enterprise encapsulan lógica y datos de negocio y exponen sus interfaces, y con ellos la complejidad de los servicios distribuidos, a la capa de cliente.

PROBLEMA

En un entorno de las aplicaciones multicapa de la Plataforma Java 2, se pueden encontrar los siguientes problemas:

Acoplamiento fuerte, que provoca la dependencia directa entre los clientes y los objetos de negocio.

Demasiadas llamadas a métodos entre el cliente y el servidor, abocando a problemas de rendimiento de la red.

Falta de una estrategia de acceso uniforme de los clientes, exponiendo los objetos de negocio a una mala utilización.

Una aplicación J2EE multicapa tiene numerosos objetos del lado del servidor que se implementan como beans enterprise. Además, otros objetos arbitrarios podrían proporcionar servicios, datos o las dos cosas. A estos objetos los conocemos colectivamente como objetos de negocio, ya que encapsulan datos y lógica de negocio.

Las aplicaciones J2EE implementan objetos de negocio que proporcionan servicios de procesamiento como beans de sesión. Los objetos de negocio genéricos que representan una vista de un objeto de almacenamiento persistente y que es compartido por varios usuarios, normalmente se implementan como beans de entidad.

El acoplamiento fuerte entre objetos también se obtiene cuando los objetos manejan sus relaciones entre ellos mismos. Frecuentemente, no está claro donde se manejan las relaciones. Esto provoca la complejidad de las relaciones entre los objetos de negocio y la rigidez en la aplicación. Esta falta de flexibilidad hace las aplicaciones menos manejables cuando se necesita hacer cambios.

Aparece otro problema cuando un cliente interactúa directamente con los objetos de negocio. Como los objetos de negocio se exponen directamente a los clientes, no hay una estrategia unificada para acceder a ellos. Sin dicha estrategia uniforme de acceso por parte del cliente, los objetos de negocio se ven expuestos a los clientes y se podría reducir su utilización consistente.

CAUSAS

• Proporcionar a los clientes un interface sencillo que oculte todas interacciones complejas entre los componentes de negocio.
• Reducir el número de objetos de negocio que se exponen al cliente a través de la capa de servicio sobre la red.
• Ocultar al cliente las interacciones y las interdependencias entre los componentes de negocio. Esto proporciona una mejor manejabilidad, centralización de interacciones (responsabilidades), mayor flexibilidad, y mayor habilidad para soportar los cambios.
• Proporcionar una capa de servicio uniforme para separar la implementación de los objetos de negocio de la abstracción del servicio de negocio.
• Evitar la exposición directa de los objetos de negocio a los clientes para mantener el acoplamiento entre las dos capas al mínimo.

SOLUCIÓN
Usar un bean de sesión como una fachada (facade) para encapsular la complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo. El Session Facade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a los clientes.
Session Facade abstrae las interacciones de los objetos de negocio y proporciona una capa de servicio que expone sólo los interfaces requeridos. Así, oculta a la vista de los clientes las interacciones complejas entre los participantes. El Session Facade controla las interacciones entre los datos de negocio y los objetos de servicio de negocio que participan en el flujo de trabajo, y encapsula la lógica de negocio asociada con los requerimientos, Así, el bean de sesión (representando al Session Facade) maneja las relaciones entre los objetos de negocio. El bean de sesión también maneja el ciclo de vida de los participantes creando, localizando (buscando), modificando, y borrándolos según lo requiera el flujo de trabajo. En una aplicación compleja, el Session Facade podría delegar este control del estilo de vida en un objeto separado. Por ejemplo, para controlar el estilo de vida de los beans de sesión e identidad participantes, Session Facade podría delegar este trabajo a un objeto Service Locator.

ESTRUCTURA
La siguiente figura representa el diagrama de clases del patrón Session Facade.

PARTICIPANTES Y COLABORACIONES
La siguiente figura contiene el diagrama de secuencia que muestra las interacciones de un Session Facade con dos beans de entidad, un bean de sesión y un DAO, todos actuando como participantes en el cumplimiento de la petición del cliente.

Client- Representa al cliente del Session Facade, que necesita acceder al servicio de negocio. Este cliente puede ser otro bean de sesión (Session Facade) en la misma capa de negocio o un Business Delegate en otra capa.

SessionFacade- El SessionFacade se implementa como un bean de sesión. Maneja la relaciones entre varios objetos de negocio y proporciona una abstracción de alto nivel para el cliente. El SessionFacade ofrece acceso genérico a los BusinessObject participantes representados por la llamada Invoke en el bean de sesión.

BusinessObject- BusinessObject es un objeto de rol que facilita la aplicación de diferentes estraegias, como beans de sesión, de entidad o DAO. Un BusinessObject proporciona datos y/o algún servicio del diagrama de clases. El SessionFacade interactúa con varios ejemplares de BusinessObject para proporcionar el servicio.

CONSECUENCIAS

• Introduce la Capa Controladora para la Capa de Negocio 
• Expone un Interface Uniforme 
• Reduce el Acoplamiento, Incrementa la Manejabilidad 
• Mejora el Rendimiento, Reduce los Métodos Específicos 
• Proporciona Acceso Genérico 
• Centraliza el Control de Seguridad 
• Centraliza el Control de Transacciones 
• Expone Menos Interfaces Remotos a los Clientes

PATRÓN MODEL VIEW CONTROLLER (MVC)

Es un patrón 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.

El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

DESCRIPCIÓN DEL PATRÓN MVC

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.

• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.

• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

PATRÓN INTERCEPTING FILTER

CONTEXTO

El mecanismo de manejo de peticiones de la capa de presentación recibe muchos tipos diferentes de peticiones, cada uno de los cuales requiere varios tipos de procesamiento. Algunas peticiones simplemente requieren su reenvio al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.

PROBLEMA

Se requiere un pre-procesamiento y un post-procesamiento de unas peticiones o respuestas de un cliente Web.

Cuando una petición entra a una aplicación Web, normalmente debe pasar varios test de entrada antes del estado de procesamiento principal. Por ejemplo,

¿Se ha autentificado el cliente?

¿Tiene el cliente una sesión válida?

¿La dirección IP del cliente es de una red conocida?

¿Viola alguna restricción el path de la petición?

¿Qué codificación usa el cliente para enviar los datos?

¿Soportamos el tipo de navegador del cliente?

Algunos de estos chequeos son tests, que resultan en una respuesta de si o no que determina si continuará el procesamiento. Otros chequeos manipulan el stream de datos entrantes a una forma aceptable para el procesamiento.

La solución básica consiste en un serie de chequeos condicionales, si cualquiera de ellos falla la petición se aborta. Las sentencias if/else anidadas son una estrategia estándar, pero esta solución tiene fragilidad de código y un estilo de programación de copiar-y-pegar, porque el flujo del filtrado y la acción de los filtros se compila dentro de la aplicación.

La clave para solventar este problema de una forma flexible y no obstrusiva es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente completa una acción de filtrado específica.

CAUSAS

• Procesamiento común, como un chequeo del esquema de codificación de datos o la información de login de cada petición, completo por cada petición.
• Se desea la centralización de la lógica común.
• Se debería facilitar la adición o eliminación de sevicios sin afectar a los componentes existentes, para que se puedan utilizar en gran variedad de combinaciones, como
• Logging y autentificación.
• Depuración y transformación de la salida para un cliente específico
• Descomprensión y conversión del esquema de codificación de la entrada.

SOLUCIÓN
Crear filtros conectables para procesar servicios comunes de una forma estándar sin requerir cambios en el código principal del procesamiento de la petición. Los filtros interceptan las peticiones entrantes y las respuestas salientes, permitiendo un pre y post-procesamiento. Podemos añadir y eliminar estos filtros a discreción, sin necesitar cambios en nuestro código existente.
Podemos, en efecto, decorar nuestro procesamiento principal con una variedad de servicios comunes, como la seguridad, el logging, el depurado, etc. Estos filtros son componentes independientes del código de la aplicación principal, y pueden añadirse o eliminarse de forma declarativa. Por ejemplo, se podría modificar un fichero de configuración de despliegue para configurar una cadena de filtros. Cuando un cliente pide un recurso que corresponde con este mapeo de URL configurado, se procesa cada filtro de la cadena antes de poder invocar el recurso objetivo.

ESTRUCTURA
La siguiente figura representa el diagrama de clases del patrón Intercepting Filter.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura representa el diagrama de la secuencia del patrón Intercepting Filter.

FilterManager- El FilterManager maneja el procesamiento de filtros. Crea el FilterChain con los filtros apropiados, en el orden correcto e inicia el procesamiento.

FilterChain- El FilterChain es una collection ordenada de filtros independientes.

FilterOne, FilterTwo, FilterThree- Estos son los filtros individuales que son mapeados a un objetivo. El FilterChain coordina su procesamiento.

Target- El Target es el recurso que el cliente ha solicitado.

CONSECUENCIAS

• Centraliza el Control con Controladores de Acoplamiento Ligero 
• Mejora la Reutilización 
• Configuración Declarativa y Flexible 
• La Compartición Información es Ineficiente