Introdução ao Spring MVC

Escrever uma aplicação web em Java sem framework é um exercício instrutivo, e ninguém o faz duas vezes. É preciso declarar uma servlet por tela, ler os parâmetros manualmente em HttpServletRequest, convertê-los a partir de strings, verificar se não estão ausentes, decidir o que fazer quando a conversão falha, escolher um código de status e, por fim, escrever o HTML caractere por caractere no fluxo de saída. O código de negócio — as três linhas que realmente importam — se afoga nesse encanamento, e esse encanamento é reescrito a cada tela.

O problema não é a quantidade de código. É que esse código repetitivo é código de decisão. Cada servlet decide sozinha como interpretar a requisição, como sinalizar um erro, como produzir sua resposta. Depois de trinta telas, uma aplicação contém trinta convenções ligeiramente divergentes, e qualquer mudança transversal — adicionar um log, impor um formato de data, tratar os erros de maneira uniforme — vira uma caça ao tesouro em trinta arquivos.

O Spring MVC responde a isso com uma inversão: em vez de deixar cada tela se virar sozinha, uma única servlet recebe todas as requisições da aplicação e orquestra seu tratamento. Essa servlet não sabe nada do seu negócio; ela apenas sabe identificar o trecho de código responsável por uma URL, fornecer a ele parâmetros já convertidos e validados e, depois, transformar o valor de retorno em resposta HTTP. Seu trabalho se resume então a escrever métodos Java que recebem objetos e devolvem objetos.