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 patrón 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, esto 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 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, la delegación del procesamiento de negocio, el control de 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 reducir la lógica de negocios en la vista permite reutilizar el código entre peticiones.

Usualmente, un controlador se coordina con un componente AplicationController, que es el encargado de manejar la acción y la vista asociada. Asi, AplicationController elige la siguiente vista para el usuario y dirige el control al recurso. Este patrón sugiere la centralización de la gestión de peticiones, pero no limita el número de manejadores en el sistema como, por ejemplo,  lo hace 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

Este patrón maneja todas las peticiones . 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.
  • 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: