Service To Worker

Este patrón está asociado al controlador, es responsable del acceso al modelo y maneja la navegación de la capa de presentación.

Contexto

El sistema controla el flujo de ejecución y accede a los datos de negocio, desde los que crea el contenido de la presentación.

Problema

El problema es una combinación de los problemas resueltos por los patrones Front Controller y View Helper de la capa de presentación. No hay un componente centralizado para manejar el control de acceso, la recuperación de contenido o el manejo de la vista, y hay código de control duplicado esparcido por varias vistas. Además, la lógica de negocio y la de formateo de la presentación están mezcladas en esas vistas, haciendo que el sistema sea menos flexible, menos reutilizable y generalmente menos resistente a los cambios.

Mezclar lógica de negocio con el procesamiento de la vista también reduce la modularidad y proporciona una pobre separación de roles entre los equipos de producción web y de desarrollo de software.

Solución

Combinar un Controller y un AplicationManager con los patrones View y Command para manejar peticiones de clientes y preparar una presentación dinámica como respuesta. Los controladores delegan la recuperación de contenido en los Helpers, que manejan el relleno del modelo intermedio para la View. Un Dispatcher es el responsable del control de la View y la navegación y puede encapsularse dentro de un Controller o de un componente separado.

Service to Worker describe la combinación de los patrones Front Controller y View Helper con un componente Dispatcher. Aunque este patrón y Dispatcher View describen una estructura similar, ambos sugieren diferentes divisiones de la labor entre los componentes. En Service to Worker, el Controller y el Dispatcher tienen más responsabilidades.

Aunque los patrones Service to Worker y Dispatcher View representan una combinación de otros patrones del catálogo, el primero garantiza con su nombre una comunicación eficiente entre los desarrolladores, mientras que el segundo sugiere una recuperación de contenido relegada al momento de procesamiento de la vista.

En el patrón Dispatcher View, el Dispatcher normalmente juega un rol moderado en el control de la View. En el patrón Service to Worker, el Dispatcher juega un rol algo más elevado en el control de la View.

Un rol limitado para el Dispatcher ocurre cuando no se utiliza recursos exteriores para poder elegir la View. La información encapsulada en la petición es suficiente para determinar la View a la que despachar la petición. Por otro lado, en el patrón Service to Worker, el Dispatcher podría invocar servicios de negocio para determinar la View apropiada que se debe mostrar.

La estructura compartida de Service to Worker y Dispatcher View consiste en un controlador trabajando con un Dispatcher, Views y Helpers.

Implementación y Participantes

• Controller: El Controller normalmente es el punto de contacto inicial para manejar una petición. Funciona con un Dispatcher para completar el control de la vista y la navegación. El Controller maneja la autentificación, la autorización, la recuperación de contenido, la validación y otros aspectos del manejo de la petición. Delega en los Helpers para completar partes de este trabajo.
• Dispatcher: Un Dispatcher es el responsable del control de la vista y la navegación, controlando la elección de la siguiente vista a mostrar y proporcionando el mecanismo para dirigir el control a este recurso. Un Dispatcher se puede encapsular dentro de un Controller o puede ser un componente independiente que trabaja en coordinación con el Controller. El Dispatcher puede proporcionar reenvío estático a la vista o podría proporcionar un mecanismo de reenvío dinámico más sofisticado.
• View: Una vista o View representa una presentación de información al cliente. La información utilizada en esta presentación se recupera de un modelo. Los Helpers soportan Views encapsulando y adaptando un modelo para utilizarlo en una presentación.
• Helper: Un Helper es el responsable de ayudar al View o al Controller a completar su procesamiento. Así, los Helpers tienen numerosas responsabilidades, incluyendo la obtención de los datos requeridos por la View y almacenándolos en el modelo intermedio, en cuyo caso el Helper es conocido como un ValueBean Además, los Helpers podrían adaptar este modelo de datos para que los utilice la vista. Los Helpers pueden servir peticiones de datos desde la View simplemente proporcionando acceso a los datos en bruto o formateándolos como contenido web.
• BussinesService: Es un rol que cumple el servicio al que el cliente quiere acceder. Normalmente, se accede al servicio de negocio mediante un BusinessDelegate. El rol del BusinessDelegate es proporcionar control y protección para el servicio de negocio.

A continuación se muestra un diagrama de secuencia de las colaboraciones entre los componentes: