Dans l'exemple suivant, le paramètre ScriptFile
est marqué avec une annotation @Valid
.
Que fait l'annotation @Valid
?
@RequestMapping(value = "/scriptfile", method = RequestMethod.POST)
public String create(@Valid ScriptFile scriptFile, BindingResult result, ModelMap modelMap) {
if (scriptFile == null) throw new IllegalArgumentException("A scriptFile is required");
if (result.hasErrors()) {
modelMap.addAttribute("scriptFile", scriptFile);
modelMap.addAttribute("showcases", ShowCase.findAllShowCases());
return "scriptfile/create";
}
scriptFile.persist();
return "redirect:/scriptfile/" + scriptFile.getId();
}
C'est à des fins de validation.
Validation Il est courant de valider un modèle après avoir lié les entrées utilisateur à ce dernier . Le printemps 3 fournit un support pour validation déclarative avec JSR-303 . Ce support est activé automatiquement si un fournisseur JSR-303, tel que Hibernate Validator, est présent sur votre classpath. Une fois activé, vous pouvez déclencher la validation simplement par annoter une méthode Controller paramètre avec l'annotation @Valid: Après avoir lié le POST entrant paramètres, le formulaire de rendez-vous sera être validé; dans ce cas, pour vérifier la valeur du champ de date n'est pas nulle et se produit à l'avenir.
Regardez ici pour plus d'infos:
http://blog.springsource.com/2009/11/17/spring-3-type-conversion-and-validation/
En ajoutant aux réponses ci-dessus, jetez un oeil à la suite. AppointmentForm
's date
La colonne est annotée avec quelques annotations. En ayant l'annotation @Valid
qui déclenche des validations sur la AppointmentForm
(dans ce cas, @NotNull
et @Future
). Ces annotations peuvent provenir de différents fournisseurs de JSR-303 (par exemple, Hibernate, Spring, etc.).
@RequestMapping(value = "/appointments", method = RequestMethod.POST)
public String add(@Valid AppointmentForm form, BindingResult result) {
....
}
static class AppointmentForm {
@NotNull @Future
private Date date;
}
IIRC @Valid n'est pas une annotation Spring, mais une annotation JSR-303 (qui est le standard de validation de bean). En gros, il vérifie si les données que vous envoyez à la méthode sont valides ou non (cela validera le scriptFile pour vous).
@Valid
en soi n'a rien à voir avec Spring. Cela fait partie de la spécification Bean Validation (il y en a plusieurs, la dernière en date étant la JSR 380 à compter du second semestre de 2017), mais @Valid
est très ancien et provient entièrement de la JSR 303.
Comme nous le savons tous, Spring est très efficace pour l'intégration avec toutes les différentes bibliothèques JSR et Java en général (pensez à JPA, JTA, Caching, etc.) et bien sûr, ces personnes se sont également occupées de la validation. L'un des composants clés facilitant cette opération est MethodValidationPostProcessor .
Essayer de répondre à votre question - @Valid
est très pratique pour ce que l’on appelle la validation en cascade lorsque vous souhaitez valider un graphique complexe et pas seulement les éléments de niveau supérieur d’un objet. Chaque fois que vous voulez aller plus loin, vous devez utiliser @Valid
. C'est ce que dicte JSR. Spring se conformera à cela avec quelques écarts mineurs (par exemple, j'ai essayé de mettre @Validated
au lieu de @Valid
sur la méthode RestController et les travaux de validation, mais cela ne s'appliquera pas aux beans "de service" classiques).
public String create(@Valid @NotNull ScriptFile scriptFile, BindingResult result, ModelMap modelMap) {
if (scriptFile == null) throw new IllegalArgumentException("A scriptFile is required");
Je suppose que cette annotation @NotNull
est valide donc si la condition n'est pas nécessaire.
En ajoutant simplement la réponse ci-dessus, dans une application Web @valid
est utilisé lorsque le bean à valider est également annoté avec des annotations de validation, par exemple. @NotNull
, @Email
(annotation hibernate) afin que, lors de la saisie de l'utilisateur, les valeurs puissent être validées et que le résultat de la liaison ait les résultats de la validation .bindingResult.hasErrors()
indiquera si une validation a échoué.
Un autre aspect pratique de @Valid non mentionné ci-dessus est que (c'est-à-dire: utiliser Postman pour tester un noeud final) @Valid formatera la sortie d'un appel incorrect REST en JSON formaté au lieu d'un blob de texte difficilement lisible. Ceci est très utile si vous créez une API consommable dans le commerce pour vos utilisateurs.