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, que suelen ser datos persistentes dentro de un SGBD. Pero también pueden ser datos procedentes 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 al margen de la interfaz web y, en particular, con una interfaz de consola. Suele ser la capa más estable de la arquitectura. No cambia aunque se modifique 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 la misma.

La comunicación va de izquierda a derecha:

el usuario realiza una solicitud a la capa [interface utilisateur]
esta solicitud es formateada por la capa [interface utilisateur] y transmitida 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 situada a su izquierda hasta que se envía la respuesta final al usuario.

Las capas [métier] y [dao] se utilizan normalmente a través de interfaces Java. Así, la capa [métier] solo conoce de la capa [dao] su interfaz o interfaces, 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 ninguna repercusión 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 ha podido procesar correctamente
- una página de confirmación en caso contrario
el controlador elige la respuesta (= vista) que se va a enviar al cliente. Elegir la respuesta que se va a enviar al cliente requiere varios pasos:
- seleccionar el objeto que generará la respuesta. Es lo que se denomina 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 dicha respuesta. De hecho, esta suele contener información calculada por el controlador. Esta información conforma lo que se denomina el modelo M de la vista, la M de MVC.
- Por lo tanto, el paso 3 consiste en elegir una vista V y en construir el modelo M necesario para ella.
El controlador C solicita que se muestre la vista seleccionada. En la mayoría de los casos, esto consiste en ejecutar un método concreto de la vista V encargado de generar la respuesta al cliente. En este documento, denominaremos «vista» tanto al objeto que genera la respuesta al cliente como a la propia respuesta. La documentación MVC no es explícita en este punto. Si fuera la respuesta la que debiera denominarse «vista», podríamos llamar «generador de vista» al objeto que genera dicha respuesta.
El generador de vista V utiliza la plantilla M preparada 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 vistas. Puede ser un flujo HTML, PDF, Excel, etc.

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 de desarrollo web. Un método que se puede utilizar para aplicaciones sencillas es el siguiente:

el controlador lo gestiona un único servlet. Es la «C» de MVC.
Todas las solicitudes del cliente contienen un atributo «action», por ejemplo (http://.../appli?action=liste).
En función del 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].
En función del resultado de la ejecución, el método [doAction] decide qué página JSP se va a mostrar. Se trata de la vista V del modelo MVC.
La página JSP contiene elementos dinámicos que debe proporcionar el servlet. El método [doAction] se encargará de proporcionar dichos elementos. Se trata del modelo de la vista, la «M» de MVC. Esta plantilla se suele colocar en el contexto de la solicitud (request.setAttribute("clave", "valor")), o, con menos 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 transfiriendo 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 denomina «Front Controller» o patrón de controlador único. Un único servlet gestiona todas las solicitudes de todos los usuarios.

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

Esta arquitectura se corresponde con la siguiente arquitectura ntier:

En realidad, solo hay una capa: la de la interfaz web. En general, una aplicación web MVC basada en servlets y páginas JSP 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] hay que ejecutar para procesar la acción solicitada por el usuario
en realidad solo se diferencian en el contenido de dichos métodos [doAction]

Entonces, la tentación de:

factorizar el procesamiento (1) en un servlet genérico que ignore 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 denominadas «frameworks», para proporcionar 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 framework 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.