4. Desarrollo de MVC (Modelo – Vista – Controlador)

Una aplicación web suele tener una arquitectura de tres capas:

la capa [dao] se encarga del acceso a los datos, por lo general datos persistentes dentro de un SGBD. Pero también pueden ser datos que provienen de sensores, de la red, etc.
La capa [metier] implementa los algoritmos «de negocio» de la aplicación. Esta capa es independiente de cualquier tipo de interfaz con el usuario. Por lo tanto, debe poder utilizarse tanto con una interfaz de consola como con una interfaz web o una interfaz de cliente enriquecida. Así, debe poder probarse fuera de la interfaz web y, en particular, con una interfaz de consola. Por lo general, es la capa más estable de la arquitectura. No cambia si se modifica la interfaz de usuario o la forma de acceder a los datos necesarios para el funcionamiento de la aplicación.
la capa [interface utilisateur], que es la interfaz (a menudo gráfica) que permite al usuario controlar la aplicación y recibir información de ella.

La comunicación va de izquierda a derecha:

el usuario realiza una solicitud a la capa [interface utilisateur]
Esta solicitud es procesada por la capa [interface utilisateur] y se transmite a la capa [métier]
Si para procesar esta solicitud la capa [métier] necesita datos, los solicita a la capa [dao]
cada capa consultada envía su respuesta a la capa de la izquierda hasta llegar a la respuesta final para el usuario.

Las capas [métier] y [dao] se utilizan normalmente a través de interfaces de Java. De este modo, la capa [métier] solo conoce de la capa [dao] su(s) interfaz(es) y desconoce las clases que las implementan. Esto es lo que garantiza la independencia de las capas entre sí: cambiar la implementación de la capa [dao] no tiene ningún impacto en la capa [métier], siempre y cuando no se modifique la definición de la interfaz de la capa [dao]. Lo mismo ocurre entre las capas [interface utilisateur] y [métier].

La arquitectura MVC (Modelo – Vista – Controlador) se integra en la capa [interface utilisateur] cuando esta es una interfaz web:

El procesamiento de una solicitud de un cliente se lleva a cabo siguiendo los siguientes pasos:

el cliente envía una solicitud al controlador. Este recibe todas las solicitudes de los clientes. Es la puerta de entrada de la aplicación. Es la C de MVC.
El controlador C procesa esta solicitud. Para ello, puede necesitar la ayuda de la capa de negocio. Una vez procesada la solicitud del cliente, esta puede generar diversas respuestas. Un ejemplo clásico es:
- una página de errores si la solicitud no se pudo procesar correctamente
- una página de confirmación en caso contrario
el controlador elige la respuesta (= vista) que se enviará al cliente. Elegir la respuesta que se enviará al cliente requiere varios pasos:
- seleccionar el objeto que generará la respuesta. A esto se le llama la vista V, la V de MVC. Esta elección depende, por lo general, del resultado de la ejecución de la acción solicitada por el usuario.
- proporcionarle los datos que necesita para generar esa respuesta. De hecho, esta suele contener información calculada por el controlador. Esta información forma lo que se conoce como el modelo M de la vista, la M de MVC.
- El paso 3 consiste, por lo tanto, en elegir una vista V y en construir el modelo M necesario para ella.
El controlador C solicita a la vista elegida que se muestre. Por lo general, esto implica ejecutar un método específico de la vista V encargado de generar la respuesta para el cliente. En este documento, llamaremos «vista» tanto al objeto que genera la respuesta para el cliente como a la respuesta misma. La documentación MVC no es explícita en este punto. Si fuera la respuesta la que debiera llamarse vista, podríamos llamar generador de vista al objeto que genera dicha respuesta.
El generador de vista V utiliza el modelo M preparado por el controlador C para inicializar las partes dinámicas de la respuesta que debe enviar al cliente.
La respuesta se envía al cliente. La forma exacta de esta depende del generador de vista. Puede ser un flujo HTML, PDF, Excel, ...

La metodología de desarrollo web MVC no requiere necesariamente herramientas externas. Así, se puede desarrollar una aplicación web en Java con una arquitectura MVC utilizando un simple JDK y las bibliotecas básicas para el desarrollo web. Un método que se puede utilizar para aplicaciones sencillas es el siguiente:

el controlador lo realiza un único servlet. Este es el C de MVC.
Todas las solicitudes del cliente contienen un atributo «action», por ejemplo (http://.../appli?action=liste).
Según el valor del atributo «action», el servlet ejecuta un método interno de tipo [doAction(...)].
El método [doAction] ejecuta la acción solicitada por el usuario. Para ello, si es necesario, utiliza la capa [métier].
Según el resultado de la ejecución, el método [doAction] decide qué página JSP se mostrará. Esta es la vista V del modelo MVC.
La página JSP tiene elementos dinámicos que deben ser proporcionados por el servlet. El método [doAction] proporcionará estos elementos. Este es el modelo de la vista, la M de MVC. Este modelo se coloca, por lo general, en el contexto de la solicitud (request.setAttribute("clave", "valor")), o, con menor frecuencia, en el contexto de la sesión o de la aplicación. Una página JSP tiene acceso a estos tres contextos.
El método [doAction] muestra la vista al transferir el flujo de ejecución a la página JSP seleccionada. Para ello, utiliza una instrucción del tipo [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)].

Este patrón de diseño (Design Pattern) MVC se conoce como el patrón «Front Controller» o patrón de controlador único. Un único servlet procesa todas las solicitudes de todos los usuarios.

Volvamos a la arquitectura de la aplicación web anterior:

Esta arquitectura corresponde a la siguiente arquitectura ntier:

De hecho, solo hay una capa: la de la interfaz web. En general, una aplicación web basada en servlets y páginas MVC tendrá la siguiente arquitectura:

Para aplicaciones sencillas, esta arquitectura es suficiente. Cuando se han desarrollado varias aplicaciones de este tipo, se observa que los servlets de dos aplicaciones diferentes:

tienen el mismo mecanismo para determinar qué método [doAction] se debe ejecutar para procesar la acción solicitada por el usuario
en realidad solo se diferencian en el contenido de estos métodos [doAction]

Por lo tanto, existe una gran tentación de:

factorizar el procesamiento (1) en un servlet genérico que no tenga conocimiento de la aplicación que lo utiliza
delegar el procesamiento (2) a clases externas, ya que el servlet genérico no sabe en qué aplicación se utiliza
establecer la conexión entre la acción solicitada por el usuario y la clase que debe procesarla mediante un archivo de configuración

Han surgido herramientas, a menudo llamadas «frameworks», para brindar estas facilidades a los desarrolladores. El más antiguo y probablemente el más conocido de ellos es Struts (http://struts.apache.org/). Jakarta Struts es un proyecto de la Apache Software Foundation (www.apache.org). Este marco de trabajo se describe en (http://tahe.developpez.com/java/struts/).

El marco Spring (http://www.springframework.org/), de aparición más reciente, ofrece funcionalidades similares a las de Struts. Su uso se ha descrito en varios artículos (http://tahe.developpez.com/java/springmvc-part1/).

A continuación, presentamos un ejemplo de arquitectura MVC basada en servlets y páginas JSP.