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. La siguiente figura
muestra un esquema de ello:
Este elemento provee un controlador centralizado
para gestionar las peticiones webs a la aplicación. Un controlador frontal
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.
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.
·
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.
Al usar un
controlador como el punto inicial de contacto para manejar las peticiones. El
controlador maneja las 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.
Un controlador se coordina con un
componente dispatcher. Los dispatchers son responsables del control de la vista y de la
navegación. Así, un dispatcher elige la siguiente vista por el usuario y dirige el control
al recurso. Los dispatchers podrían encapsularse directamente dentro del controlador o
se puede extraer en un componente separado.
Aunque el patrón Front Controller sugiere
la centralización del manejo de peticiones, no limita el número de manejadores
en el sistema.
·
Estructura (diagrama de clases)
·
Diagrama de secuencia
·
Participantes
1)
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.
2)
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.
El dispatcher utiliza un objeto RequestDispatcher (soportado en la especificación Servlet) y encapsula algún
procesamiento adicional.
3)
Helper
Un helper es el responsable de ayudar a la vista
o al controlador a completar su procesamiento. Los helpers tienen muchas responsabilidades,
incluyendo la recopilación de los datos requeridos por la vista y el
almacenamiento en el modelo intermedio. Además, los helpers pueden adaptar este modelo de datos
para usarlo en la vista.
Una vista podría trabajar con
cualquier número de helpers,
que normalmente son componentes JavaBeans
4)
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.
