Struts, el MVC más utilizado en Java
En Liferay el núcleo está diseñado con servlets, portlets y Struts, así que es necesario conocer bien Struts para poder trabajar con soltura. Como vamos a ver Struts es un MVC potente pero complejo por lo que su uso no es inmediato y no es recomendado en proyectos pequeños, donde soluciones basadas en JSPs pueden ser suficientes.
Un poco de historia
Leyendo la historia y motivaciones de Struts o puedo dejar de relacionarla con mi propia historia del desarrollo de aplicaciones web. En 1997 me tocó comenzar a jugar con el protocolo CGI para extender las posibilidades de HTTP, programando en C. Poco a poco nos fuimos pasado de C a Perl e incluso a otros lenguajes como "shell script". Apache por aquél entonces estaba bastante limitado a servir contenidos estático y el poder ejecutar programas externos, que utilizaban todas las librerías que tenían disponibles, y devolver los resultados vía Apache al cliente web, era todo un avance. Se podían llegar a hacer interfaces basadas en CGI que por ejemplo, administraran un sistema.
¿Qué problemas tenía CGI? Por un lado la escalabilidad: cada petición lanzaba un proceso. Y además, los procesos entre sí no estaban comunicados por lo que había que buscar mecanismos alternativos a esta comunicación. La entrega y recogido de datos de HTTP no era muy amigable (aunque en seguida surgieron librerías que la simplificaron). Y había que configurar Apache para decirle donde estaban los CGIs y realizar la traducción entre URLs y CGIs. Por otro lado las librerías disponibles no estaban pensadas para la web, por lo que tocaba a veces programar funciones como el análisis de URL, conversión de una texto a codificación compatible con URLs ...
Un avance para simplificar todo esto vino de la mano e PHP. Un lenguaje de programación pensado para hacer páginas web dinámicas. PHP se puede ejecutar como un CGI, en cuyo caso tiene la problemática de los CGIs, o bien se puede ejecutar como un módulo de Apache, caso en el que la integración es mayor lo que permite por ejemplo no depender de programas externos (CGIs) algo que simplifica la instalación y el mantenimiento. Las librerías de PHP estaban ya pensadas para realizar páginas web por lo que sus librerías dan ya muchas funcionalidades que se necesitaban en la web (tratamiento de cadenas, posteriormente las sesiones, autenticación ...). En la misma línea que PHP llegaron mayores integraciones con la web de otros lenguajes como Python o Perl, con sus respectivos módulos para Apache mod_perl y mod_python.
El ciclo de vida de tratamiento de una petición HTTP se podía hacer ya de forma completa desde el propio servidor que es extendido para poder utilizar librerías de otros lenguajes y entornos. Se recibe una petición (acción) con unos datos (parámetros), se lleva a cabo a cabo la petición con la lógica que corresponda (modelo de funcionamiento y de datos) y finalmente se devuelve el resultado al cliente con una página HTML (vista).
En Java se propusieron inicialmente los servlets como mecanismo de programación Java de aplicaciones web, resultando un sistema bastante similar al de mod_php o mod_python o mod_perl, con la principal diferencia de que un servlet sólo se crea una vez, la primera vez que se invoca, y luego se lanzan hebras sobre su método de atención de petición para ir dando el servicio, algo que ayuda al rendimiento. Además, esto facilita el compartir información entre diferentes invocaciones de un servlet. La gran diferencia con respecto a PHP es que en en este era más sencillo el incorporar código HTML a la página, mientras que con los servlets esto se ha de hacer desde Java de forma pesada. El como enlazar la lógica de atención de una petición (en Java, PHP o Python) de la visualización (HTML a veces con Javascript) es uno de los grandes problemas que han existido en el desarrollo web, llevando en casos a programas inmantenibles al terminar siendo una mezcla difícil de seguir de lógica de ejecución con HTML mezclado.
Los servlets no gestionaban bien esta mezcla y obligaban a llenar el código Java de "println" para visualizar el HTML de salida. Esto fue así hasta la llegada de Java Server Pages que seguía ya un modelo muy similar al de PHP: por defecto la página se considera HTML pero tiene marcas donde se puede insertar lógica. Pero este modelo nos lleva a tener decenas de páginas separadas, con lógica de la aplicación dispersa por ellas (difícil de reutilizar) y en general, nos lleva a un modelo poco mantenible, poco modular y poco reutilizable. La solución pasa por minimizar la lógica dentro de estas páginas HTML, que prácticamente sea sólo lógica de visualización, y que toda la lógica de negocio y el modelo de datos, se encuentre en librerías que se usen desde estas páginas HTML, o vistas. En PHP esto se logra creando librerías que pueden ser utilizadas desde todas las páginas y en Java de la misma forma. Pero, si no se obliga a seguir un flujo de trabajo que potencie esta separación, la lógica de aplicación acabará en las páginas HTML.
Es por ello que se han ido definiendo diferentes modelos de desarrollo, por ejemplo potencia el uso de plantillas para crear el HTML y separar aún más la lógica del código. En el caso de Java se puede decir que el motor de plantillas podrían ser las JSP y toda la lógica de la aplicación residir en servlets, clases Java. Esto nos lleva al Modelo-2 de Java (el Modelo-1 son las JSP) donde se logra separar la vista de la lógica de negocio de forma bastante robusta. Este Modelo-2 ya está muy cercano al MVC (Model View Controller) y Struts viene para terminar de fijar los pilares de un entorno de programación MVC.