1.2.7 Intercepting Filter

El mecanismo de manejo de petición de niveles de presentación recibe muchos tipos diferentes de peticiones, que requieren diversos tipos de procesamiento. Algunas peticiones son simplemente enviados a la componente de controlador adecuado, mientras que las demás solicitudes deben ser modificados, auditado o no comprimido antes de ser procesados ​​posteriormente.

Ø  Procesamiento común, tales como comprobar el esquema de codificación de datos o de registro de la información acerca de cada petición, completa por solicitud.

Ø  Se desea centralización de la lógica común.

Ø  Los servicios deben ser fáciles de añadir o eliminar discretamente sin afectar a los componentes existentes, de modo que puedan ser utilizados en una variedad de combinaciones, tales como

• Registro y autenticación.
• Depuración y transformación de la producción para un cliente específico.
• Uncompressing y la conversión de esquema de codificación de entrada.

Estructura

Diagrama de secuencia

Ø  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 coleccion 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.

1.2.8 Model –View-Controller

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

El patrón de arquitectura "modelo vista controlador", es una filosofía de diseño de aplicaciones, compuesta por:

Ø  Modelo

o   Contiene el núcleo de la funcionalidad (dominio) de la aplicación.

o   Encapsula el estado de la aplicación.

o   No sabe nada / independiente del Controlador y la Vista.

Ø  Vista

o   Es la presentación del Modelo.

o   Puede acceder al Modelo pero nunca cambiar su estado.

o   Puede ser notificada cuando hay un cambio de estado en el Modelo.

Ø  Controlador

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

Para entender cómo funciona nuestro patrón Modelo vista controlador, se debe entender la división a través del conjunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores externos a el modelo principal. Para ello, es importante saber que el controlador interpreta las entradas del usuario (tanto teclado como el ratón), enviado el mensaje de acción al modelo y a la vista para que se proceda con los cambios que se consideren adecuados

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

Utilizado en múltiples frameworks

Ø  Java Swing

Ø  Java Enterprise Edition (J2EE)

Ø  XForms (Formato XML estándar del W3C para la especificación de un modelo de proceso de datos XML e interfaces de usuario

Ø  Como formularios web)

Ø  GTK+ (escrito en C, toolkit creado por Gnome para construir

Ø  aplicaciones gráficas, inicialmente para el sistema X Window)

Ø  ASP.NET MVC Framework (Microsoft)

Ø  Google Web Toolkit (GWT, para crear aplicaciones Ajax con Java)

Ø  Apache Struts (framework para aplicaciones web J2EE)

Ø  Ruby on Rails (framework para aplicaciones web con Ruby)

Ø  Etc., etc., etc.

 Modelo pasivo

No es necesario para el modelo hacer ninguna tener alguna disposición a él, simplemente basta con tener en cuenta su existencia. El modelo no tiene ninguna responsabilidad para comunicar los cambios a la vista porque ocurren solo por orden del usuario, por lo que esta función la llevara a cabo el controlador porque será el que interprete las ordenes de este usuario debido a que solo debe comunicar que algo ha cambiado. Por esto, el modelo es se encuentra en modo inconsciente y su participación en este caso es irrisoria.

Unión del modelo con la vista y el controlador

Como no todos los modelos pueden ser pasivos, necesitamos algo que comunique al controlador y a la vista, por lo que en este caso, sí que necesitamos el modelo, ya que solo este puede llevar a cabo los cambios necesarios al estado actual en el que estos se encuentran.

Al contrario que el modelo, que puede ser asociado a múltiples asociaciones con otras vistas y controladores, cada vista solo puede ser asociada a un único controlador, por lo que han de tener una variable de tipo controler que notificara a la vista cuál es su controlador o modelo asignado. De igual manera, el controlador tiene una variable llamada View que apunta a la vista. De esta manera, pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a su modelo.

Al final, la vista es quien lleva la responsabilidad de establecer la comunicación entre los elementos de nuestro patrón MVC. Cuando la vista recibe un mensaje que concierne al modelo o al controlador, lo deja registrado como el modelo con el cual se comunicara y apunta con la variable controller al controlador asignado, enviándole al mismo su identificación para que el controlador establezca en su variable view el identificador de la vista y así puedan operar conjuntamente. El responsable de deshacer estas conexiones, seguirá siendo la vista, quitándose a sí misma como dependiente del modelo y liberando al controlador.

Diagrama de secuencia del patrón MVC

Ø  El usuario activa el evento.

Ø  El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista).

Ø  El modelo (si es necesario) llama a la vista para su actualización.

Ø  Para cumplir con la actualización la Vista puede solicitar datos al Modelo.

Ø  El Controlador recibe el control.

Objetivo

•      Aislar los cambios de la interfaz gráfica de usuario y evitar que estos cambios impliquen cambiar la lógica de dominio de la aplicación.

•      Reducir la distancia humano-máquina y facilitar los cambios de la interfaz de usuario.

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

Ø  Está sujeto a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC

Ø  Para desarrollar una aplicación bajo el patrón de diseño MVC es necesario una mayor dedicación en los tiempos iniciales del desarrollo (desarrollar un mayor número de clases).

Ø  MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para modificar y comunicar los módulos de una aplicación.

Ø  MVC es un patrón de diseño orientado a objetos por lo que su implementación es sumamente costosa y difícil en lenguajes que no siguen este paradigma.

Ejemplo de MVC en aplicaciones web

Vista:

• la página HTML

Controlador:

• código que obtiene datos dinámicamente y genera el contenido HTML

Modelo:

• la información almacenada en una base de datos o en XML junto con las reglas de negocio que transforman esa información (teniendo en cuenta las acciones de los usuarios)

MVC en java swing

Modelo:

•      El modelo lo realiza el desarrollador

Vista:

•      Conjunto de objetos de clases que heredan de java.awt.Component

Controlador:

•      El controlador es el thread de tratamiento de eventos, que captura y propaga los eventos a la vista y al modelo Clases de tratamiento de los eventos (a veces como clases anónimas) que implementan interfaces de tipo EventListener (ActionListener, MouseListener, WindowListener, etc.

1.2.9 Service Locator

El patrón de localización de servicios es un patrón de diseño utilizados en el desarrollo de software para encapsular los procesos involucrados en la obtención de un servicio con una fuerte capa de abstracción . Este modelo utiliza un registro central conocido como el "servicio de localización", que a petición devuelve la información necesaria para realizar una tarea determinada.

Ventajas

Ø El "servicio de localización" puede actuar como un simple enlazador en tiempo de ejecución. Esto permite que el código a ser añadido en tiempo de ejecución sin volver a compilar la aplicación, y en algunos casos incluso sin tener que reiniciarlo.

Ø Las aplicaciones pueden optimizar los mismos en tiempo de ejecución mediante la adición selectiva y eliminar elementos del localizador de servicios. Por ejemplo, una aplicación puede detectar que tiene una mejor biblioteca para la lectura de imágenes JPG disponibles de la predeterminada, y cambiar el registro correspondiente.

Ø Grandes secciones de una biblioteca o aplicación puede ser completamente separados. El único vínculo entre ellos se convierte en el registro.

Desventajas

Ø Cosas colocados en el registro son cajas negras con eficacia en lo que respecta al resto del sistema. Esto hace que sea más difícil de detectar y recuperarse de sus errores, y puede hacer que el sistema en su conjunto menos fiable.

Ø El registro debe ser único, el cual puede hacer que sea un cuello de botella para las aplicaciones concurrentes.

Ø El registro puede ser un problema de seguridad grave, ya que permite a los forasteros para inyectar código correcto en una aplicación.

Ø El registro se esconde dependencias de la clase ', causando errores de tiempo de ejecución en lugar de errores en tiempo de compilación cuando las dependencias que faltan.

Ø El registro hace que el código sea más difícil de mantener (en lugar de utilizar la inyección de dependencia), porque se vuelve claro cuando iba a introducir un cambio importante

Ø El registro hace que el código más difícil de probar, ya que todas las pruebas tienen que interactuar con el mismo servicio de clase mundial localizador para establecer las dependencias falsas de una clase bajo prueba.

Participantes y Responsabilidades

Diagrama de secuencia de Service Locator




Ø Cliente
Este es el cliente del Servicio de localización. El cliente es un objeto que normalmente requiere el acceso a los objetos de negocio como un Business Delegate.

Ø Servicio de localización

El Service Locator abstrae los servicios de búsqueda de nombres (API), las dependencias de proveedores, las complejidades de búsqueda y creación de objetos de negocio y proporciona una interfaz sencilla para los clientes.

Ø InitialContext


El objeto InitialContext es el punto de partida en el proceso de búsqueda y creación. Los proveedores de servicios ofrecen el objeto de contexto, que varía dependiendo del tipo de objeto de negocio proporcionada por búsqueda el localizador de servicio y el servicio de la creación. Un Servicio de localización que ofrece servicios para varios tipos de objetos de negocio (como beans enterprise y componentes JMS, etc) utiliza múltiples tipos de objetos de contexto, cada uno obtenido de un proveedor diferente

Ø ServiceFactory

El objeto ServiceFactory representa un objeto que proporciona gestión del ciclo de vida de los objetos BusinessService. El objeto ServiceFactory para beans enterprise es un objeto EJBHome. El ServiceFactory para componentes JMS puede ser un objeto JMS ConnectionFactory, como un TopicConnectionFactory (para publicar / suscribir modelo de mensajería) o una QueueConnectionFactory (de punto a punto de modelo de mensajería).

Ø BusinessService

El BusinessService es un rol que cumple el servicio al cliente está tratando de acceder. El objeto BusinessService se crea o se miró hacia arriba o removido por el 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. El TopicConnection y QueueConnection a continuación, se pueden utilizar para producir un objeto JMSSession, tales como TopicSession o un QueueSession respectivamente.

1.2.10 Session Facade

Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.

El patrón fachada viene motivado por la necesidad de estructurar un entorno de programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones y dependencias entre éstos.

Características
Ø 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.

Ventajas
Una de las ventajas de utilizar este patrón a la hora de controlar los permisos de los usuarios. Cada usuario tiene un rol (administrador, invitado, usuario registrado, etc.) y, para controlar los permisos de cada rol, lo único que hay que hacer es definir las operaciones de cada rol en distintos sesión beans de la capa de control y después, desde el deployment descriptor de los EJBs, mapear nuestros roles con dichos sesión beans. La autenticación se realiza en la capa de interfaz.


Desventajas.
Ø Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que tratan los clientes y haciendo que el subsistema sea más fácil de usar.

Ø Promueve un débil acoplamiento entre el subsistema y sus clientes. Muchas veces los componentes de un subsistema sin que sus clientes se vean afectados, las fachadas ayudan a estructurar en capas un sistema y las dependencias entre los objetos. También pueden eliminar dependencias complejas o circulares. Esto puede ser una consecuencia importante cuando el cliente y el subsistema se implementan por separado.

En los grandes sistemas de software es vital reducir las dependencias de compilación. Queremos ahorrar tiempo minimizando la recopilación cuando cambien las clases del subsistema. Reducir las dependencias de compilación con fachada puede limitar la compilación necesaria para un pequeño cambio en un subsistema importante. Una fachada puede simplificar portar sistemas en otras plataformas ya que es menos probable que construir un subsistema requiera volver a construir todos los otros.Ø No impiden que las aplicaciones usen las clases del subsistema en caso de que sea necesario. De este modo se puede elegir entre la facilidad de uso y generalidad.

Estructura



Participantes 


Ø Client (EJBAccountFacadeDelegate)

Puede ser un Business Delegate u otro Session Facade

Ø SessionFacade (AccountFacadeEJB)

Normalmente, un Session Bean proporciona un interfaz sencillo al cliente, ocultando las  relaciones entre numerosos objetos de negocioSession Facade (7)


Participantes (cont)

Ø Business Object (Account y AccountOperation)

Proporciona datos (Entity Bean o DAO) o un servicio (SessionBean)

A la hora de implementar una fachada deben tenerse en cuenta los siguientes aspectos:


Ø Reducción del acoplamiento cliente-subsistema. El acoplamiento entre clientes y el subsistema puede verse reducido todavía más haciendo que Fachada sea una clase abstracta con subclases concretas para diferentes implementaciones de un subsistema. De esa manera los clientes pueden comunicarse con el subsistema a través de la interfaz de una clase abstracta Fachada. Este acoplamiento abstracto evita que los clientes tengan que saber que implementación de un subsistema están usando.
Ø Clases del subsistema del subsistema públicas o privadas. Un subsistema se parece a una clase en que ambos tienen interfaces y los dos encapsulan algo – una clase encapsula estado y operaciones, mientras que un subsistema encapsula clases. Y del mismo modo resulta útil pensar en la interfaz pública y privada de una clase, también podemos pensar en la interfaz pública y privada de un subsistema.

Ø La interfaz pública de un subsistema consiste en una serie de clases a las que acceden todos los clientes; la interfaz privada es solo para quienes vayan a ampliar el subsistema. La clase fachada es parte de la interfaz pública, por supuesto pero no es la única. Otras clases del subsistema también suelen ser públicas.

1.2.11 Transfer Object

Java 2 Platform, Enterprise Edition (J2EE) implementan componentes de negocio del lado del servidor como beans de sesión y beans de entidad. Algunos métodos expuestos por los componentes de negocio devuelven datos al cliente. A menudo, el cliente invoca métodos get de un objeto de negocio varias veces hasta obtener todos los valores de los atributos.

Los beans de sesión representan los servicios a las empresas y no se comparten entre los usuarios. Un bean de sesión proporciona métodos de servicios de granularidad gruesa cuando se implementa por el patrón Session Facade.

Los beans de entidad, por otro lado, son multiusuario, objetos transaccionales que representan datos persistentes. Un bean de entidad expone los valores de los atributos, proporcionando un método de acceso (también referido como un captador o método get ) para cada atributo que desea exponer.

Causas
Ø Todos los accesos a un bean enterprise se realizan mediante interfaces remotos. Cada llamada a un bean enterprise potencialmente es una llamada a un método remoto con sobrecarga de red.

Ø Normalmente, las aplicaciones tienen transacciones de lectura con mayor frecuencia que las de actualización. El cliente solicita los datos desde la capa de negocio para su presentación, y otros tipos de procesamientos de sólo-lectura. El cliente actualiza los datos de la capa de negocio con mucha menos frecuencia con la que los lee.

Solución

Utilizar un Transfer Object para encapsular los datos de negocio. Se utiliza una única llamada a un método para enviar 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

Estructura 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. El constructor podría aceptar todos los valores de atributos del bean de entidad para el que se ha diseñado el Transfer Object

Diagrama de secuencia Transfer Object 

Consecuencias.

Ø Transfiere Más Datos en Menos Llamadas Remotas
En lugar de realizar múltiples llamadas sobre la red al BusinessObject para obtener los valores de los atributos, esta solución proporciona una sola llamada a un método.

Ø Reduce el Tráfico de Red
Un Transfer Object transfiere los valores desde el bean de entidad al cliente en una llamada a un método remoto. El Transfer Object actúa como un transportista de datos y reduce el número de llamadas remotas requeridas para obtener los valores de los atributos del bean; y esto significa un mejor rendimiento de la red.

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

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. Esto depende de la aplicación y de la implementación de este patrón.

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

Ø 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. Esto depende de la aplicación y de la implementación de este patrón.

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.

Estructura Value List Handler

Ø ValueListIterator

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

• o getSize() obtiene el tamaño de la hoja de resultados.
• o getCurrentElement() obtiene el Transfer Object actual de la lista.
• o getPreviousElements(int howMany) obtiene una colección de Transfer Objects que son anteriores en la lista al elemento actual.
• o getNextElements(int howMany) obtiene una colección de Transfer Objects que son posteriores en la lista al elemento actual.
• o 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. ValueListHandlerejecuta 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. Cuando el cliente solicita los resultados, ValueListHandler obtiene los Transfer Objects desde el ValueList cacheado, crea una nueva colección de Transfer Objects, serializa la colección y la envía de vuelta al cliente. ValueListHandler también sigue la pista del índice actual y del tamaño de la lista.

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

Diagrama de secuencia Value List Handler

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
Se necesita cachear los resultados obtenidos de la ejecución de la consulta cuando un cliente debe mostrarlos en pequeñas partes en vez de una gran lista

Ø Proporciona una Mayor Flexibilidad de Consulta

1.2.13 View Helper

Este patrón se centra en diversificar las responsabilidades de nuestras aplicaciones.

Contexto

El sistema crea el contenido de la presentación, lo que requiere el procesamiento de datos de negocio dinámicos.

Problema

La capa de presentación suele tender a realizar modificaciones constantemente. Si la lógica de negocio y el acceso a datos se mezclan con el formato de presentación, estos cambios son costosos y complejos de implementar. Mezclar la lógica de negocio y de sistema con el procesamiento de la vista reduce la modularidad y también proporciona una pobre separación de los roles entre los equipos de producción web y de desarrollo de software.

Solución

Basándonos en los principios del Modelo-Vista-Controlador, una vista delega sus responsabilidades de procesamiento en sus clases de ayuda, implementadas como JavaBeans o etiquetas personalizadas. Las clases de ayuda o Helpers también almacenan el modelo de datos intermedio de la vista y sirven como adaptadores de datos de negocio.


Delegar la lógica de negocio en otra capa externa a la de presentación hace que nuestra aplicación sea más modular y facilita la reutilización de componentes. Varios clientes, como controladores y vistas, podrían utilizar el mismo Helper para recuperar y adaptar estados del modelo similares para su presentación en varias vistas. De esta manera eliminamos redundancia en nuestros códigos.


El patrón View Helper se enfoca en recomendar formas de particionar las responsabilidades de nuestras aplicaciones.

Implementación y Participantes

Ø Cliente: Realiza la petición.


Ø View: Una vista representa y muestra información al cliente. La información que se muestra se recupera de un modelo. LosHelpers soportan Views encapsulando y adaptando un modelo para utilizarlo.


Ø Helper: Un Helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento incluyendo la obtención de los datos requeridos por la vista y su almacenamiento en el modelo intermedio, en cuyo caso algunas veces nos podemos referir al Helper como un ValueBean.


Ø BussinesService: El servicio de negocio es un rol que cumple el servicio al que está accediendo el cliente.


Ø ValueBean: Un ValueBean es un otro nombre para un Helper que es responsable de contener el estado del modelo intermedio para que lo utilice una vista.

Diagrama de secuencia de View Helper