Introducción a Spring MVC

Escribir una aplicación web en Java sin framework es un ejercicio instructivo, y nadie lo hace dos veces. Hay que declarar un servlet por pantalla, leer los parámetros a mano en HttpServletRequest, convertirlos desde cadenas de caracteres, comprobar que no faltan, decidir qué hacer cuando la conversión falla, elegir un código de estado y, por último, escribir el HTML carácter a carácter en el flujo de salida. El código de negocio —las tres líneas que de verdad importan— se ahoga en esa fontanería, y esa fontanería se reescribe en cada pantalla.

El problema no es la cantidad de código. Es que ese código repetitivo es código de decisión. Cada servlet decide por sí solo cómo interpretar la petición, cómo señalar un error, cómo producir su respuesta. Al cabo de treinta pantallas, una aplicación contiene treinta convenciones ligeramente divergentes, y el menor cambio transversal —añadir una traza, imponer un formato de fecha, gestionar los errores de manera uniforme— se convierte en una búsqueda del tesoro por treinta archivos.

Spring MVC responde a esto con una inversión: en lugar de dejar que cada pantalla se las arregle, un servlet único recibe todas las peticiones de la aplicación y orquesta su tratamiento. Este servlet no sabe nada de su negocio; solo sabe identificar el fragmento de código responsable de una URL, proporcionarle parámetros ya convertidos y validados, y transformar su valor de retorno en una respuesta HTTP. Su trabajo se reduce entonces a escribir métodos Java que reciben objetos y devuelven objetos.