Acesso a dados

Até aqui, os dados da aplicação viviam em listas na memória. Isso bastava para entender o roteamento e o binding de formulários, mas é insustentável além disso: tudo desaparece na reinicialização, nada é compartilhado entre duas instâncias e nenhuma consulta um pouco mais refinada pode ser expressa.

A migração para um banco de dados relacional é o momento em que muitas aplicações Spring MVC se degradam. O controller, até então enxuto, passa a abrir conexões, escrever SQL e gerenciar transações. Encontramos try/catch/finally sobre recursos JDBC, código de mapeamento de ResultSet para objeto e um tratamento de erros que varia de um método para outro. O controller volta a ser exatamente o que o Spring MVC deveria eliminar: um lugar onde tudo se mistura.

O problema não é apenas estético. Misturar acesso a dados e camada web torna as transações incontroláveis. Um método de controller que grava em três tabelas sem uma fronteira transacional explícita pode deixar o banco em um estado intermediário se a terceira escrita falhar, e nada no código indica que esse risco existe.