Discussion :

[Katachana]

Bonjour,

Je suis a la recherche de bonne pratique / convention en terme de gestion des données dans un controller.

A l'initialisation de mes controllers je charge des données provenant de la base : Une partie ne sera jamais modifiée (ex : alimentation de liste déroulante) et une autre pourra être dynamique en fonction des choix utilisateurs.

Pour l'instant je n'ai utilisé qu'un objet ViewBean contenant toute les informations en le déclarant comme @SessionAttribute.

Mais du coup cet objet me sert à la fois a binder les informations de mon formulaire et a stocker des informations statiques qui seront afficher dans la page ou utilisées dans le controller.

N'y aurait-il pas un pattern / une conception plus intelligente a utiliser pour avoir un découpage plus claire ?

Merci d'avance !

[BugFactory]

Personnellement, je préfère avoir un objet qui représente les champs saisis par l'utilisateur, que je lie à la requête plutôt qu'à la session.

Les listes déroulantes sont des objets séparés, typiquement créés par des méthodes avec l'annotation @ModelAttribute. A moins que les options ne dépendent de l'utilisateur connecté, je pense qu'elles ne devraient pas être dans la session. Sur une méthode, @ModelAttribute indique qu'il faut appeler la méthode pour ajouter un objet au modèle. L'intérêt est que ces méthodes sont appelées automatiquement, sans qu'il soit nécessaire de le faire dans les méthodes gérant les actions de l'utilisateur. Ainsi on sépare clairement les traitements à effectuer en réaction à une action de l'utilisateur de l'initialisation des champs.

Imaginons par exemple le contrôleur d'un formulaire permettant de choisir une langue avec une liste déroulante. La liste des langues vient d'une base de données. GET affiche le formulaire, POST l'enregistre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
@Controller
@RequestMapping("/language.html")
public class LanguageController {
 
    private static class LanguageForm {
 
        private long languageId;
 
        // Constructeur getter setter etc.
    }
 
    @Autowired
    private LanguageService languageService;
 
    @RequestMapping(method = RequestMethod.GET)
    public ModelAndView() display() {
        LanguageForm languageForm = new LanguageForm();
 
        // Initialisation du formulaire vide etc.
 
        return new ModelAndView("languageView", "form", languageForm);
    }
 
    @RequestMapping(method = RequestMethod.POST)
    public ModelAndView() save(@ModelAttribute @Valid LanguageForm languageForm, BindingResult bindingResult) {
        if(!bindingResult.hasErrors()) {
            Language language = languageService.find(languageForm.getLanguageId());
 
            // Traitements du choix du langage.
        }
        return new ModelAndView("languageView", "form", languageForm);
    }
 
    @ModelAttribute("languagesList")
    public List<Language> populateLanguagesList() {
         return languageService.findAll();
    }
}

Ce code n'est qu'un exemple et pourrait être amélioré mais il montre bien l'intérêt de la méthode. L'objet Form contient exactement les mêmes champs que le formulaire. L'initialisation de la liste des langues est dans une méthode à part, elle ne vient pas encombrer le code des méthodes display ou save. Pas de risque non plus de la mettre dans display et de l'oublier dans save. Le formulaire n'est pas enregistré en session, pas de fuite de mémoire. Si la liste des langages ne change pas, on pourrait charger languagesList une seule fois à l'initialisation du controller plutôt qu'à chaque nouvelle session.

[footsteps]

Je procède en model.addAttribut().
De ce fait tu peux choisir ce que tu y stockes (statique comme tu dis ou dyna /formulaire).