Accès aux données

Jusqu'ici, les données de l'application vivaient dans des listes en mémoire. C'était suffisant pour comprendre le routage et la liaison de formulaire, et c'est intenable au-delà : tout disparaît au redémarrage, rien n'est partagé entre deux instances, et aucune requête un peu fine n'est exprimable.

Le passage à une base de données relationnelle est le moment où beaucoup d'applications Spring MVC se dégradent. Le contrôleur, jusque-là sobre, se met à ouvrir des connexions, écrire du SQL, gérer des transactions. On y trouve des try/catch/finally sur des ressources JDBC, du code de mappage ResultSet vers objet, et une gestion d'erreur qui varie d'une méthode à l'autre. Le contrôleur redevient exactement ce que Spring MVC était censé éliminer : un endroit où tout se mélange.

Le problème n'est pas seulement esthétique. Mélanger accès aux données et couche web rend les transactions incontrôlables. Une méthode de contrôleur qui écrit dans trois tables sans frontière transactionnelle explicite peut laisser la base dans un état intermédiaire si la troisième écriture échoue — et rien dans le code ne signale que ce risque existe.