Uso de Patrones J2EE de la Capa de Presentación

Estos filtros son los encargados de capturar las peticiones y realizar la lógica de preprocesado que permite identificar a las mismas, asi como las respuestas salientes que utilizamos en las actividades de post-procesado. Podemos añadir y eliminar estos filtros a discreción, sin necesitar cambios en nuestro código existente.

Estos filtros son componentes independientes del código de la aplicación principal, y pueden añadirse o eliminarse de forma declarativa.

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.

Este patrón se aplica cuando 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, implementando un controlador único.

Este patrón está asociado al controlador, es responsable del acceso al modelo y maneja la navegación de la capa de presentación. Puede ser aplicado en casos en los que 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. 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, estando mezclada la lógica de negocio con el procesamiento de la vista.

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.

Este patrón se centra en diversificar las responsabilidades de nuestras aplicaciones. La aplicabilidad de este patrón se centra en situaciones en las que el sistema crea el contenido de la presentación, lo que requiere el procesamiento de datos de negocio dinámicos. La capa de presentación debe realizar modificaciones constantemente y es necesario no mezclar la lógica de negocio y el acceso a datos.

Delegar la lógica de negocio en otra capa externa a la de presentación hace que nuestra aplicación sea más modular y facilita la reutilización de componentes. Varios clientes, como controladores y vistas, podrían utilizar el mismo Helper para recuperar y adaptar estados del modelo similares para su presentación en varias vistas. De esta manera eliminamos redundancia en nuestros códigos.

Este patrón ayuda al proceso de integración de varias subvistas en una página. Puede aplicarse cuando se tiene una funcionalidad compuesta por un conjunto de vistas asociadas, existiendo varias subvistas que se integren para completar una sóla página, siendo necesario estandarizar este proceso de integración y composición para facilitar el desarrollo por parte de un equipo compuesto por varias personas.

Se trata de un patrón de diseño modelo-vista-controlador en el que la vista es manejada por sus propios componentes. La situación en la que puede aplicarse este patrón es aquella en la que 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, sin que haya un componente centralizado para el manejo de las vistas.

Dispatcher View describe la combinación de los patrones Front Controller y View Helper con un componente Dispatcher.