lunes, 8 de julio de 2013

TRANSFER OBJECT

Cuando se trabaja con arquitecturas de varias capas, un problema típico es cómo pasar los datos de una capa a otra. En el caso de la biblioteca que veíamos anteriormente, cuando por ejemplo queremos ver los datos de un libro, éstos tienen que sacarse de la base de datos, pasando por las capas de datos y negocio hasta la capa de presentación. Solicitar los datos uno a uno (título, autores, ISBN,...) no es una opción adecuada ya que en aplicaciones distribuidas incrementa innecesariamente el número de llamadas remotas. Necesitamos una forma compacta y organizada de pasar estos datos de una capa a otra.

Un transfer object no es más que un objeto que "empaqueta" datos para que puedan viajar entre las capas. Dicho objeto contendrá todos los datos que nos interesen accesibles mediante getters y setters

Nótese que aunque los transfer objects están directamente relacionados con los objetos del modelo de objetos del dominio,no se trata de los mismos objetos. Los objetos del dominio pueden contener lógica de negocio mientras que como ya se ha dicho los transfer objects son meros almacenes de datos. Además no tiene por qué haber una relación uno-a-uno entre objetos del dominio y transfer objects.

Destacamos algunos puntos importantes:

Por cada objeto de negocio puede haber más de un transfer object

De hecho, un estragegia muy común es usar un transfer object distinto para cada caso de uso.

Un problema importante es el de la sincronización entre los valores del transfer object y los del objeto del dominio que representa. Hay que asegurarse de que dichos valores están actualizados o que una falta de actualización de los mismos no conlleve consecuencias graves (caso típico de las operaciones de solo lectura). 


Algunas características de estos objetos son:

 Se reduce el tráfico de red, agrupando varias solicitudes en una sola.

 Aumenta la complejidad del diseño debido a la sincronización remota y problemas de control de versiones, debido a que varias instancias son agrupadas en un solo objeto.



Estructura

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, dependendiendo de los requerimientos.
Participantes 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. 

TransferObjectTransferObject 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. El constructor podría aceptar todos los valores de atributos del bean de entidad para el que se ha diseñado el Transfer Object. Normalmente, los miembros del Transfer Object se definen como públicos, así eliminan la necesidad de los métodos get y set. Si se necesita alguna protección, los miembros podrían definirse como protected o private, y se definirían métodos get para sus valores. Si no ofrece métodos set para los valores, un Transfer Object está protegido frente a modificaciones después de su creación. Si sólo se permite la modificación de unos pocos miembros para facilitar las actualizaciones, entonces si que se de deben proporcionar métodos set. Por lo tanto, la creación del Transfer Object varía dependiendo de los requerimientos de la aplicación. 


SERVICE LOCATOR (LOCALIZACIÓN DE SERVICIO)



Diseño orientado a objetos puede conducir al desarrollo de complejos de clase estructuras con componentes que dependen de otros tipos. Si las clases dependientes instancian sus dependencias directamente que se dice que están estrechamente acoplados. Esto disminuye la flexibilidad de los componentes y aumenta el esfuerzo necesario para cambiar la funcionalidad y los tipos de sustitución. En un artículo anterior he descrito los patrones de diseño de inyección de dependencia que las clases desacoplarse de sus dependencias. El patrón de diseño localizador de servicios es un enfoque alternativo para la promoción de acoplamiento débil, pero no requiere la inyección de dependencias a través de las interfaces, constructores o propiedades.

En lugar de crear instancias de la clase depende directamente de sus dependencias, se les solicita de un servicio de localizador de objeto centralizada.

El patrón de diseño localizador de servicio se basa en la creación de una clase, llamada el localizador de servicios, que sabe cómo crear las dependencias de otros tipos. A menudo, el localizador de servicios actúa como un depósito para objetos de servicio pre inicializado. Cuando se requiere uno de estos se solicita el uso de un método de la clase. En otras situaciones, los métodos de localización de servicios instancias de objetos a medida que se necesitan, posiblemente utilizando la información de configuración se pasa a del método parametros.

Estructura

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








Participantes


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 dependiendo del tipo de objetos de negocio proporcionados por el servicio de búsqueda y creación del Service Locator. Un Service Locator que proporciona los servicios para varios tipos de objetos de negocio (como beans enterprise, componentes JMS, etc.) utiliza varios tipos de objetoscontext, cada uno obtenido de un proveedor diferente (por ejemplo, el proveedor de contexto para un servidor de aplicaciones EJB podría ser diferente del proveedor de contexto para un servicio JMS).

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 objetoEJBHome.

BusinessService
BusinessService es un rol que cumple el servicio que el cliente ha solicitado.El objetoBusinessService 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. 


Requisitos de Implementación

  • Soporte de herencia 
  • Manejo de excepciones 
  • Comunicación remota con objetos 




MODELO VISTA CONTROLADOR (MVC)

El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación).
De esta forma, dividimos el sistema en tres capas donde, como explicaremos más adelante, tenemos la encapsulación de los datos, la interfaz o vista por otro y por último la lógica interna o controlador.
El patrón de arquitectura "modelo vista controlador", es una filosofía de diseño de aplicaciones, compuesta por:
  • Modelo

Contiene el núcleo de la funcionalidad (dominio) de la aplicación.
Encapsula el estado de la aplicación.
No sabe nada / independiente del Controlador y la Vista.
  • Vista

Es la presentación del Modelo.
Puede acceder al Modelo pero nunca cambiar su estado.
Puede ser notificada cuando hay un cambio de estado en el Modelo.
  • Controlador

Reacciona a la petición del Cliente, ejecutando la acción adecuada y creando el modelo pertinente.



Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:
1.      El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace)
2.      El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
3.      El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4.      El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
5.      La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

     Comunicación
El modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los otros, de manera que sea coherente con las iteraciones que el usuario realizara. Como es lógico la comunicación entre la vista y el controlador es bastante básica pues están diseñados para operar juntos, pero los modelos se comunican de una manera diferente, un poco más sutil.

      Ventajas
  •          La implementación se realiza de forma modular.
  •          Clara separación entre interfaz, lógica de negocio y de presentación.
  •          Sus vistas muestran información actualizada siempre.
  •          Cualquier modificación que afecte al dominio, como aumentar métodos o datos contenidos, implica una modificación sólo en el modelo y las interfaces del mismo con las vistas
  •           Las modificaciones a las vistas no afectan al modelo de dominio
  •          Sencillez para crear distintas representaciones de los mismos datos
  •          Facilidad para la realización de pruebas unitarias de los componentes.
  •           Reutilización de los componentes.
  •           Simplicidad en el mantenimiento de los sistemas.
  •          Facilidad para desarrollar prototipos rápidos.
  •        Los desarrollos suelen ser más escalables


Desventajas
  •  El tiempo de desarrollo de una aplicación que implementa el patrón de diseño MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una aplicación que no lo implementa, ya que MVC requiere que el programador implemente una mayor cantidad de clases que en un entorno de desarrollo común no son necesarias. Sin embargo, esta desventaja es muy relativa ya que posteriormente, en la etapa de mantenimiento de la aplicación, una aplicación MVC es muchísimo más mantenerle, extensible y medicable que una aplicación que no lo implementa.
  • MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para medicar y comunicar los módulos de una aplicación.
  • Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos para poder proporcionar las modificaciones que genera el modelo de aplicación; una clase Modelo, otra clase Vista y una clase Controlador genéricas que realicen todas las tareas de comunicación, notificación y actualización que serán luego transparentes para el desarrollo de la aplicación.

SESSION FACADE

El patrón Fachada proporciona una interfaz unificada de alto nivel para un subsistema, que oculta las interfaces de bajo nivel de las clases que lo implementan. Con esto se consiguen dos objetivos fundamentales: hacer el subsistema más fácil de usar y desacoplar a los clientes de las clases del subsistema.

Crea una fachada para encapsular las complejas interrelaciones de los distintos elementos de negocio.
Proporciona un servicio uniforme y maneja el flujo de ejecución de los subelementos.

Por todo esto se deberá aplicar el patrón Fachada cuando se de alguna de las siguientes circunstancias:
En general cuando por algún motivo se desee dotar de una interfaz sencilla y usable a un subsistema complejo. Una fachada proporciona una vista por defecto de la funcionalidad del subsistema suficiente para la mayoría de los programadores.
Cuando se detecten demasiadas dependencias entre las clases clientes de una abstracción y las clases que implementan esta abstracción en un subsistema. En este caso debe introducirse una fachada que permita diseñar a los clientes y otros subsistemas para que dependan de una interfaz y no de una implementación. Cuando se quiera estructurar un sistema en subsistemas siguiendo un patrón de capas. Será de gran ayuda dotar de una fachada a cada nivel de subsistemas y utilizarla como punto de acceso al mismo. De este modo se simplificará al máximo el mantenimiento de las dependencias entre niveles. Cuando se tenga un subsistema que ofrece una funcionalidad muy rica y compleja y un conjunto significativo de clientes que solo necesitan usar una parte reducida de la misma.

Estructura
El patrón Fachada pertenece a la categoría de patrones con propósito estructural y alcance de objeto. Es decir, propone una manera de componer a sus participantes, en este caso objetos, mediante relaciones determinadas dinámicamente en tiempo de ejecución.



 Ventajas

  • Desde el punto de vista de los clientes, la fachada los aísla de los componentes del subsistema minimizando el número de objetos con los que tienen que tratar para obtener un servicio. De este modo los clientes son mucho más fáciles de escribir pues el subsistema es más sencillo de utilizar.
  • Desde el punto de vista del subsistema el uso de fachadas ayuda a organizar un sistema en capas, ayuda a controlar o eliminar las dependencias complejas o circulares entre objetos y permite hacer cambios en los componentes de un subsistema sin afectar a los clientes.
  • En general facilita enormemente el desarrollo independiente de clientes y subsistemas y tiene consecuencias muy importantes sobre la reusabilidad de los subsistemas, objetivo principal perseguido por todos los patrones de diseño.
  • En grandes sistemas de software es muy importante la aportación del patrón a la  reducción de dependencias de compilación y a la portabilidad.

Algunas consecuencias que podrían parecer “desventajas” no son tales:
  • Oculta parte de la funcionalidad de un subsistema. Esto es cierto para clientes que se decanten por la facilidad de uso de la fachada, pero nada les impide mirar más allá de la misma para aprovechar toda la generalidad del subsistema.
  • Introduce un nivel de indirección adicional que podría afectar al rendimiento de la aplicación.

Requisitos de Implementación 
  • Soporte para creación de interfaces
  • Soporte para almacenar sesión temporal del cliente
  • Comunicación remota con objetos (en el caso de agrupar servicios a clientes remotos)

COMPOSITE ENTITY

Permite implementar objetos de negocio persistentes que estén compuestos por diferentes objetos relacionados. 
Ésta patrón es implementado indirectamente por Hibernate, siendo totalmente transparente. Mediante la definición del Mapping de Hibernate, se realiza la composición de la entidad, permitiéndose cierta flexibilidad en cómo realizar dicha composición.
Los objetos del negocio tienen relaciones entre sí que son necesarias para representar correctamente el modelo del dominio. Cuando se accede a objetos remotos se podría generar una sobrecarga de red al transmitir todos los objetos relacionados que pueden ser necesarios para el cliente.
En las aplicaciones  empresariales, los objetos Composite Entity no deberían  ser expuestos directamente al cliente. Para esto se  puede usar un Session Façade. Para hacer transferencia de datos se usa el patrón Transfer Object.

Solución

Utilizar Composite Entity para modelar, representar y manejar un conjunto de objetos 

persistentes relacionados en vez de representarlos como beans de entidad específicos individuales. Un bean Composite Entity representa un grupo de objetos.

Para entender esta solución, primero definamos que significan los objetos persistentes y discutiremos sus relaciones.

Un objeto persistente es un objeto que se almacena en algún tipo de almacenamiento. Normalmente múltiples clientes comparten los objetos persistentes. Los objetos persistentes se pueden clasificar en dos tipos: objetos genéricos y objetos dependientes.

Un objeto genérico es autosuficiente. Tiene su propio ciclo de vida y maneja sus relaciones con otros objetos. Todo objeto genérico podría referenciar o contener uno o más objetos. El objeto genérico normalmente maneja el ciclo devida de estos objetos. De ahí, que esos objetos sean conocidos como objetos dependientes. Un objeto dependiente puede ser un simple objeto auto-contenido o podría a su vez contener otros objetos dependientes.

El ciclo de vida de un objeto dependiente está fuertemente acoplado al ciclo de vida del objeto genérico. Un cliente sólo podría acceder al objeto dependiente através del objeto genérico. Es decir, los objetos dependientes no se exponen directamente a los clientes porque su objeto padre (genérico) los maneja. Los objetos dependientes no pueden existir por sí mismos. En su lugar, siempre necesitan tener su objeto genérico (o padre) para justificar su existencia.

 Estructura





El diagrama de secuencia de la siguiente imagen muestra las interacciones para este patrón:



Participantes y Responsabilidades


CompositeEntity: CompositeEntity es un bean de entidad genérico. Podría ser un objeto genérico, o podría contener una referencia a un objeto genérico.

Coarse-Grained Object: Un objeto genérico es un objeto que tiene su propio ciclo de vida y que maneja sus propias relaciones con otros objetos.

DependentObject1, DependentObject2, y DependentObject3: Un objeto dependiente es un objeto que depende de un objeto genérico el cual gobierna el ciclo de vida del objeto dependiente. Un objeto dependiente puede contener otros objetos dependientes; así podría existir un árbol de objetos dentro del Composite Entity.

Estrategias: Esta sección explica las diferentes estrategias para implementar el patrón Composite Entity. Las estrategias consideran posibles alternativas y opciones para objetos persistentes (genéricos y dependientes), y la utilización deTransfer Objects.

BUSINESS DELEGATE

El Business Delegate actúa como una abstracción de negocio del lado del cliente; proporciona una abstracción para, y por lo tanto oculta, la implementación de los servicios del negocio. Utilizando Business Delegate se reduce el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio del sistema. Dependiendo de la estrategia de implementación, Business Delegate podría aislar a los clientes de la posible volatilidad en la implementación del API de los servicios de negocio. Potencialmente, esto reduce el número de cambios que se deben hacer en el código de cliente de la capa de presentación cuando cambie el API del servicio de negocio o su implementación subyacente.
Sin embargo, los métodos de interface en el Business Delegate aún podría requerir modificaciones si cambia el API del servicio de negocio. Si bien es cierto, que los cambios se harán con más probabilidad en el servicio de negocio que en el Business Delegate.
Con frecuencia, los desarrolladores son excépticos cuando un objetivo de diseño como la abstracción de la capa de negocio provoca un trabajo adicional como pago por futuras ganancias. Sin embargo, utilizando este patrón o esta estrategia resulta sólo en una pequeña cantidad de trabajo extra y proporciona unos beneficios considerables. El principal beneficio es ocultar los detalles del servicio. 

Objetivo
Facilitar el acceso de la capa cliente a la capa EJB, ocultando el API de EJB.
Un objeto que reside en la capa de presentación y en beneficio de los otros componentes de la capa de presentación llama a métodos remotos en los objetos de la capa de negocios.
Aplicabilidad
Cuando se quiere proporcionar una capa de acceso al modelo que oculta la tecnología usada en su implementación.
Utilizamos un Business Delegate para reducir el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio. El Business Delegate oculta los detalles de la implementación del servicio de negocio, como los detalles de búsqueda y acceso de la arquitectura EJB.

Estructura


 Participantes
Usa ServiceLocatorpara obtener una referencia al BusinessServiceFactory
Crea un BusinessService
(mediante BusinesServiceFactory) en el que delega las operaciones.

·        Ventajas
  • ·         Mejora el mantenimiento
  • ·         Permite separación de roles: desarrolladores de la capa cliente y desarrolladores de la capa EJB.
  • ·         Puede proporcionar caché para mejorar la eficiencia


 Implementación
En general, el Business Delegate puede ser una clase concreta usa métodos deben ser sincronizados.


 Requisitos de Implementación 
  •      Soporte de herencia
  •       Manejo de excepciones
  •       Comunicación remota con objetos

FROM CONTROLLER

Es un patrón de diseño que se basa en usar un controlador como punto inicial para la gestión de las peticiones. El controlador gestiona estas peticiones, y realiza algunas funciones como: comprobación de restricciones de seguridad, manejo de errores, mapear y delegación de las peticiones a otros componentes de la aplicación que se encargarán de generar la vista adecuada para el usuario.

El patrón Front Controller podría dividir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dispatcher. En ese caso, El Front Controller acepta todos los requerimientos de un cliente y realiza la autenticación, y el Dispatcher direcciona los requerimientos a manejadores apropiada.


Ventajas:

  • Tenemos centralizado en un único punto la gestión de las peticiones. 
  • Aumentamos la reusabilidad de código. 
  • Mejoramos la gestión de la seguridad. 

Desventajas:
  • La velocidad de respuesta disminuye al tener que ser procesadas las peticiones primero por el controlador. 

 Participantes y Responsabilidades

La siguiente figura representa el diagrama de la secuencia del patrón Front Controller. Muestra como el controlador maneja una petición: 




Controller: Es el punto de contacto inicial para manejar todas las peticiones en el sistema. El controlador podría delegar a un helper para completar la autentificación y la autorización de un usuario o para iniciar la recuperación de un contacto.

Dispatcher: Es el responsable del manejo de la vista y de la navegación, controlando la elección de la siguiente vista que se le presentará al usuario, y proporcionando el mecanismo para dirigir el control a ese recurso.
Un dispatcher se puede encapsular dentro de un controlador o se puede separar en otro componente que trabaja de forma coordinada. El dispatcher puede proporcionar un re-envío estático de la vista o un mecanismo de re-envío más sofisticado.

Helper: es el responsable de ayudar a la vista o al controlador a completar su procesamiento. Así, los helpers tienen muchas responsabilidades, incluyendo la recopilación de los datos requeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso algunas veces nos podemos referir al helper como un bean de valor. Además, los helpers pueden adaptar este modelo de datos para usarlo en la vista.
Una vista podría trabajar con cualquier número de helpers, que normalmente son componentes JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+). Además, un helper podría representar un objeto Command o un Transformador XSL, que se utiliza en combinación con una hoja de estilos para adaptar y convertir el modelo a la forma apropiada.

View: la representa y muestra información al cliente. La vista recupera información desde el modelo. Los helpers soportan las diferentes vistas encapsulando y adaptanto el modelo de datos subyacente para usarlo en el display.

domingo, 7 de julio de 2013

FAST LANE READER

Mejora el acceso de solo lectura a los datos usando JDBC.

Este patrón propone un mecanismo para obtener grandes cantidades de información utilizando un acceso directo sobre la base de datos.

Implementación


- Casos de uso que corresponden a búsquedas que devuelven una colección de objetos
- Cuando se tienen casos de uso que corresponden a búsquedas múltiples y la eficiencia es un factor importante.
* JDBC for Reading


Estructura


Participantes
Business Delegate
Delega las operaciones de búsqueda múltiple en un Session Facade (que usa un DAO) o directamente en un DAO
SessionFacade
Un Session Bean que implementa las operaciones de búsqueda múltiple delegando en un DAO
DAO
Proporciona las operaciones de búsqueda accediendo directamente a la BD
Colaboraciones
Un Business Delegate implementa las operaciones de búsqueda múltiple delegando en un Session Facade (que usa un DAO) o directamente en un DAO


Consecuencias

Beneficios
Alternativa más eficiente que operaciones findXXX en interfaces Home que devuelven múltiples Entity Beans

Riesgos

Información obsoleta (Idem Value Object)Fast-Lane Reade

INTERCEPTING FILTER


Este patrón ayuda a la detección, identificación y correcto procesamiento de las diferentes tipologías de peticiones.
El objetivo principal de este patrón es interceptar y manipular solicitudes y respuestas, antes y después que éstas sean procesadas.
Algunas aplicaciones tienen requisitos como seguridad y autenticación que pueden ser aplicables a lo largo de todas las solicitudes que se realizan. Utilizando el patrón Intercepting Filter se podrá agregar este tipo de funcionalidad para que haya cierta lógica disponible para los componentes de aplicación que la requieran.
A la hora de realizar una gestión de peticiones, una de nuestras primeras cuestiones es contemplar la tipología de las mismas. La capa de presentación recibe muchas peticiones de diversa tipología. Normalmente cada tipo de petición conlleva un tipo de procesamiento propio (reenvios a componentes, cifrado, auditadas, etc.). Resulta necesario identificar y estandarizar el procedimiento que recibe cada tipo de petición.

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 reenvió al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.


Problema

Obviamente, con este patrón vamos a tener que realizar un esfuerzo previo en decodificar las peticiones y un esfuerzo en interpretar las respuestas producidas por el cliente. Una petición web recorre varias comprobaciones previas a su procesamiento (autentificación, validación de permisos, navegador, etc.). En algunos de estas comprobaciones, se evalúa si se continua o no el procesamiento.

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.


 Solución 

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
  • Descompresión y conversión del esquema de codificación de la entrada.


 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 indenpendientes.
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.


Requisitos de Implementación

  • Soporte para creación de interfaces
  • Soporte de herencia

COMPOSITE VIEW (VISTA COMPUESTA)


Propósito
Crear Vistas Compuestas de varias sub-vistas de forma modular, flexible y extensible para construir vistas de páginas JSP para aplicaciones J2EE.  
Cuando un usuario navega a través de aplicaciones gráficas los datos y el contenido entre las diferentes páginas varía, pero muchos elementos, como una cabecera común o una barra lateral permanecen intactos en todas las vistas. La estructura y disposición de cada página puede ser la misma y algunos elementos o secciones de la página pueden aparecer en varias páginas diferentes. Cuando estos elementos y grupos se codifican directamente en la aplicación se vuelve muy difícil la tarea de modificar las vistas y se puede incurrir en inconsistencias.
La Vista Compuesta también maneja la disposición de sus sub-vistas y proporciona una plantilla, dando una apariencia consistente y facilidades a la hora de modificarla y mantenerla a lo largo de toda la aplicación.

Aplicabilidad
Se usará el patrón Composite View cuando:


  •  Varias vistas compuestas utilizan sub-vistas similares.
  •  Las porciones atómicas del contenido de una vista cambian con frecuencia.

Implementación
- Un Composite View se puede implementar siguiendo la estrategia JSP page View o bien la estrategia Servlet View. [Alur]
- El control de la vista se puede implementar de diferentes formas: utilizando etiquetas jsp estándar, como <jsp:include>, utilizando componentes JavaBeans, y también mediante etiquetas personalizadas (JSP 1.1+).

Estructura
Estructura estática del Composite View




Participantes y Colaboraciones




Vistas Compuestas
Una Vista Compuesta es una vista a la que se le han agregado varias sub-vistas.
View Manager (Controlador de Vistas)
El Controlador de Vista maneja la inclusión de fragmentos de una plantilla en la Vista Compuesta. El Controlador de Vista podría ser parte de un motor de ejecución estándar de páginas JSP, en la forma de la etiqueta <jsp:include> de JSP (véase figura), o podría   encapsularse dentro de un helper JavaBean (JSP 1.0+) o una etiqueta personalizada (JSP 1.1+) para proporcionar una funcionalidad más robusta. [Alur]
Vistas Incluidas
Una Vista Incluida es una sub-vista, una pieza atómica de una vista mayor. Esta vista incluida también podría ser una vista compuesta, incluyendo varias sub-vistas.

Consecuencias
- Cada componente de la plantilla puede incluirse dinámicamente dentro del todo y la distribución de la página puede manejarse de forma independiente del contenido.
- Esta solución es útil para la creación de vistas basadas en la inclusión y sustitución de fragmentos de plantilla modulares, tanto estáticos como dinámicos. Los diseñadores pueden hacer un prototipo de la distribución de la web, poniendo contenido estático en cada región de la plantilla. Según va progresando el desarrollo, este contenido se puede ir sustituyendo por el contenido dinámico.
- Promueve la reutilización de porciones atómicas de la vista, animando a realizar diseños modulares.
 - Es apropiado utilizar este patrón para generar páginas que muestren componentes que podrían combinarse de diferentes maneras. Esto ocurre, por ejemplo, con portales que incluyan numerosas sub-vistas independientes, como noticias, información del tiempo,   etc. en una sola página. La distribución de la página se maneja y modifica de forma independiente al contenido de las sub-vistas.
- Provoca una sobrecarga en tiempo de ejecución, un precio que hay que pagar por el incremento de flexibilidad que proporciona.