Front Controller

Patrón que centraliza el acceso de las peticiones provenientes del cliente

Contexto

La capa de presentación se encarga de gestionar el procesamiento de las peticiones de los usuarios. El objetivo de este patron es centralizar el acceso con el objetivo generalizar el mismo para todas las peticiones. Se busca implementar un controlador único.

Problema

Resulta necesario obtener un punto de acceso centralizado para vincularlo con la gestión de peticiones y de soporte a las necesidades de la capa de presentación (recuperación de contenidos, navegación, control de vistas) . Si pensamos en acceder a la vista directamente sin pasar por el  punto centralizado, puede tener las siguientes consecuencias:

• No reutilizamos código, cada vista necesita incluir sus propias necesidades lo que conlleva a duplicaciones de código ineccesarias. Afecta negativamente al control de cambios. Un cambio resulta necesario el replicarlo a todos los códigos que se han duplicado.
• Puede existir problemas con los visores, que son los encargados de la navegación 

Solución

Implementar un Controlador único Usar y usarlo 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.

El controlador proporciona un punto de entrada centralizado que controla y maneja las peticiones Web. Centralizar el control en el controlador y reduciendo la lógica de negocios en la vista permite reutilizar el código entre peticiones.

Usualmente , un controlador se coordina con un componente ApliccationController que es el encargado de manejar la acción y la vista asociada . Asi, ApliccationController elige la siguiente vista por el usuario y dirige el control al recurso. Front Controller sugiere la centralización de la gestión de peticiones, pero no limita el número de manejadores en el sistema, al modelo de como lo realiza el patrón Singleton. Una aplicación podría utilizar varios controladores , cada uno mapeado a un conjunto de servicios distintos.

Implementación y Participantes

Maneja todas las peticiones y normalmente se estructura en dos partes: un manejador WEB y una jerarquía de Comandos

• FrontController: Es el punto de contacto inicial para recoger las peticiones. Delegará en un ApplicationController para manejar la acción y la vista asociada
• Dispatcher: Sus tareas son
  • Localizar y lanzar las acciones específicas para la petición, y
  • Buscar y despachar la vista
• Helper: Realiza la acción que resuelve la petición
• View: Mostrará la información resultado al cliente

La interacción se muestra en el siguiente diagrama de secuencia: