FRONT 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 controlador proporciona un punto de entrada centralizado que controla y maneja las peticiones Web. Centralizando los puntos de decisión y control, el controlador también ayuda a reducir la cantidad de código Java, llamadas a scriptles, embebidos en la página JavaServer Pages (JSP).

Centralizar el control en el controlador y reduciendo la lógica de negocios en la vista permite reutilizar el código entre peticiones. Es una aproximación preferible a la alternativa de embeber código en varias vistas porque esta aproximación trata con entornos más propensos a errores, y de reutilización del tipo copiar-y-pegar.

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.Un controladorfrontal recibe todas las peticiones entrantes de los clientes, remitiendo a su vez cada petición al gestor de peticiones(Dispatcher) adecuado, que se encargar de gestionar la construcción de una respuesta adecuada al cliente. Son los puntos ideales para implementar servicios de seguridad, tratamiento de errores, y la gestión del control para la generación de contenidos.

·         Objeto  que acepta todos los requerimientos de un cliente y los direcciona a controladores apropiados.

·         El patrón Front Controller podría dividir la funcionalidad en 2 diferentes objetos : El front Controller y el Dispather. 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 apropiados.

CONTEXTO

El mecanismo de manejo de peticiones de la capa de presentación debe controlar y coordinar el procesamiento de todos los usuarios a través de varias peticiones. Dichos mecanismos de control se pueden manejar de una forma centralizada o descentralizada.

PROBLEMA

El sistema requiere un punto de acceso centralizado para que el manejo de peticiones de la capa de presentación soporte la integración de los servicios del sistema, recuperación de contenidos, control de vistas, y navegación. Cuando el usuario accede a la vista directamente sin pasar un mecanismo centralizado, podrían ocurrir dos problemas:

·         Se requiere que cada vista proporcione sus propios servicios del sistema, lo que normalmente resulta en duplicación de código.

·         La vista de navegación se deja a los visores. Esto podría resultar en una mezcla de contenidos y navegación.

Además, el control distribuido es más difícil de mantener, ya que los cambios se tienen que realizar en numerosos lugares.

CAUSAS

·         El procesamiento de servicios del sistema comunes se completa por cada petición. Por ejemplo, el servicio de seguridad completa los chequeos de autentificación y autorización.

·         La lógica se maneja mejor en una localización central en lugar de estar replicada dentro de varias vistas.

·         Existen puntos de decisión con respecto a la recuperación y manipulación de los datos.

·         Se utilizan varias vistas para responder a peticiones de negocio similares.

·         Puede ser muy útil un punto de contacto centralizado para manejar una petición, por ejemplo, para controlar y grabar el camino de un usuario por la site.

Los servicios del sistema y la lógica de control de vistas son relativamente sofisticados.

SOLUCIÓN

Usar un controlador como el punto inicial de contacto para manejar las peticiones. El controlador maneja el control de peticiones, incluyendo la invocación de los servicios de seguridad como la autentificación y autorización, delegar el procesamiento de negocio, controlar la elección de una vista apropiada, el manejo de errores, y el control de la selección de estrategias de creación de contenido.

ESTRUCTURA

La siguiente figura representa el diagrama de clases del patrón Front Controller.

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: El controlador 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: Un 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: Un 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.

View: Una Vista 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.

CONCLUSIÓN

Es un patrón que acepta todos los requerimientos del cliente realiza la autenticación y los direcciona a manejadores apropiados.