Je crée une API Rest à l'aide de Spring Boot et j'utilise Hibernate Validation pour valider les entrées de demande.
Mais j'ai également besoin d'autres types de validation, par exemple lorsque les données de mise à jour doivent être vérifiées, si l'ID de l'entreprise n'existe pas, je veux lever une exception personnalisée.
Cette validation doit-elle se situer au niveau de la couche service ou de la couche contrôleur?
Couche de service:
public Company update(Company entity) {
if (entity.getId() == null || repository.findOne(entity.getId()) == null) {
throw new ResourceNotFoundException("can not update un existence data with id : "
+ entity.getId());
}
return repository.saveAndFlush(entity);
}
Couche de contrôleur:
public HttpEntity<CompanyResource> update(@Valid @RequestBody Company companyRequest) {
Company company = companyService.getById(companyRequest.getId());
Precondition.checkDataFound(company,
"Can't not find data with id : " + companyRequest.getId());
// TODO : extract ignore properties to constant
BeanUtils.copyProperties(companyRequest, company, "createdBy", "createdDate",
"updatedBy", "updatedDate", "version", "markForDelete");
Company updatedCompany = companyService.update(company);
CompanyResource companyResource = companyAssembler.toResource(updatedCompany);
return new ResponseEntity<CompanyResource>(companyResource, HttpStatus.OK);
}
la source
Les validations Hibernate sont des vérifications de l' intégrité des données. Afin d'éviter les RuntimeExceptions de bbdd. Ce sont à peu près les mêmes validations que vous devriez contrôler avec des contraintes . Étant donné que seule la couche métier doit alimenter la couche de persistance, vous pouvez (ou non, selon vous) faire confiance à l'exactitude des données provenant de votre couche métier
Je ne mets pas de validations dans les DAO. J'attends des données valides des couches supérieures. En cas d'erreur je délègue au bbdd la responsabilité de connaître son contenu.
Viennent ensuite les validations au niveau de la couche métier. Toutes les validations commerciales se sont concentrées sur le maintien de la cohérence des données, pas sur leur intégrité .
Enfin je fais des validations précédentes sur la couche de contrôle. Ceux liés uniquement à une telle couche.
Vous verrez bientôt quelles validations sont censées être impliquées dans la couche métier. Le plus courant: le contrôle d'identité. Celui-ci peut facilement être implémenté sur les deux couches. Si vous vous attendez à ce que de nombreux contrôleurs ou clients consomment votre couche métier, au lieu de répéter la même validation partout, ce sera un excellent candidat à placer dans la couche métier.
Parfois, les contrôleurs ont leurs propres règles et conditions qui ne seront reproduites sur aucune autre façade. C'est alors un candidat à intégrer dans un tel contrôleur.
Pensez à ce que vous validez et si vous souhaitez l'appliquer à tout le monde, quoi qu'il arrive. Ou s'il s'agit d'une validation contextuelle ("Je valide quelque chose qui ne se produit que sur une façade de contrôle / vue particulière).
la source
Dans notre boutique Java, nous avons intentionnellement divisé la validation des widgets Web en trois opérations distinctes.
Si la couche 1 échoue, nous ne vérifions pas 2 ou 3. De même, si 1 réussit et 2 échoue, nous n'en faisons pas 3. Cela empêche la génération de messages d'erreur parasites.
Vous demandez des valeurs dans un appel REST plutôt que le contenu d'un widget, mais les mêmes principes s'appliquent.
la source
Une approche testée permet d'ombrer une lumière à ce sujet, après tout, il n'y a pas de contrôleur et vous devez choisir une autre option. De toute évidence, les règles de bussines doivent être au même endroit, et c'est une autre contrainte dans votre décision.
la source