Innanzitutto, come dichiarato da altre risposte, Hibernate Validator non consente di convalidare direttamente le primitive come nell'esempio in la domanda. Per utilizzare Hibernate Validator, definire una nuova classe contenente un valore lungo è esattamente ciò che è necessario per utilizzare Hibernate Validator.
Secondo, e il più importante, mentre la convalida programmatica è qualcosa che funziona ed è abbastanza semplice, non è pulita e manutenibile. Lasciatemi illustrare questo con alcuni esempi:
@RequestMapping(value = "testA", method = RequestMethod.POST)
@ResponseBody
public String getTestA(@RequestBody long longValue, BindingResult result) {
if (longValue > 32) {
result.rejectValue("longValue", "error.longValue", "longValue max constrained failed");
return "failed validation for test A";
} else {
return "passed validation for test A";
}
}
@RequestMapping(value = "testB", method = RequestMethod.POST)
@ResponseBody
public String getTestB(@RequestBody long longValue, BindingResult result) {
if (longValue > 32) {
result.rejectValue("longValue", "error.longValue", "longValue max constrained failed");
return "failed validation for test B";
} else {
return "passed validation for test B";
}
}
@RequestMapping(value = "testC", method = RequestMethod.POST)
@ResponseBody
public String getTestC(@RequestBody long longValue, BindingResult result) {
if (longValue > 32) {
result.rejectValue("longValue", "error.longValue", "longValue max constrained failed");
return "failed validation for test C";
} else {
return "passed validation for test C";
}
}
prima cosa da notare, è withing 3 funzioni semplici, tutto il codice di convalida è duplicato.
In secondo luogo, se a un certo punto i requisiti di convalida cambiano, e ora tutti i valori lunghi devono essere maggiori di 35, è necessario modificare ogni singola funzione di convalida, e in questo esempio è davvero semplice, perché ci sono solo 3 funzioni con la stessa validazione, ma immaginate per un momento che siano 100 funzioni in cui eseguite la stessa validazione, ora è doloroso.
Quindi, semplicemente definendo una nuova classe, con il valore lungo e l'annotazione di convalida e utilizzando tale classe su ogni metodo, è stata rimossa la duplicazione del codice e anche quando i requisiti di convalida cambiano, applicando le modifiche in un unico punto, si ha mantenuto il codice.
Inoltre, non c'è nulla di sbagliato nel dover definire le classi per un compito specifico, infatti, questo è esattamente ciò che Single Responsability Principle ti dice di fare.
Modifica: aggiunto un collegamento a una descrizione SRP.
Non penso che l'opzione wrapper sarebbe l'opzione migliore nel mio caso, perché dovrei avere un wrapper per ogni annotazione che si applica a primitive, String e tutti gli altri singoli tipi di base. E convalidandolo nel codice penso che andrebbe bene, ma vorrei mantenere una certa coerenza sul modo in cui convalidare gli oggetti. Vorrei convalidare tutti i tipi di oggetti con il validatore di ibernazione o qualcuno di loro ... Quindi non ero disposto ad ascoltare che il validatore di ibernazione non convalida questo tipo di cose: P Grazie comunque per la tua risposta! – jscherman