Validation dans la couche de service (SpringBoot)

Question

Ensuite, il y a la validation de la logique métier. Par exemple : la startDate de l'entité User doit être postérieure à un événement et le count doit être supérieur à un certain X si la date de naissance du dernier utilisateur créé est en été, sinon, l'entité devrait être rejetée par le service utilisateur.

@Service
@Transactional
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepository;

    @Autowired
    private SomeEventService someEventService ;

    @Override
    public User create(User entity) {
        String error = this.validateUser(entity);
        if (StringUtils.isNotBlank(error)) {
            throw new ValidationException(error);
        }

        return this.userRepository.save(entity);
    }
    ....
    private String validateUser(User entity) {
        SomeEvent someEvent = this.someEventService.get(entity.getName()); 
        if (entity.getStartDate().before(someEvent.getDate())) {
            return "startDate";
        }
        User lastUser = this.userRepository.findLast();
        ....
    }

}

Cependant, j'ai l'impression que ce n'est pas la meilleure approche pour gérer la validation de la logique métier. Que devrais-je faire? ConstraintValidator/HibernateValidator/écouteurs d'événements JPA ? Peuvent-ils fonctionner au niveau de la classe @Entity ou dois-je en créer X pour chaque vérification de champ différent ? Comment faites-vous dans une application de production réelle ?

Answer 1

Dans ma suggestion,

1. Utilisez la validation de champ classique par @Valid

exemple

void myservicemethod(@Valid UserDTO user)

2. Pour une validation personnalisée au niveau métier au niveau de l'entité, créez une méthode de validation dans le DTO lui-même

exemple

class UserDTO {
    //champs et getter setter
    void validate() throws ValidationException {
        //votre logique métier au niveau de l'entité
    }
}

Cette stratégie aidera à garder la logique de validation spécifique à l'entité à l'intérieur de l'entité

3. Si vous avez toujours une logique de validation qui nécessite un appel à un autre service, créez une annotation de validation personnalisée avec un ConstraintValidator personnalisé (par exemple question sur stackoverflow). Dans ce cas, ma préférence sera d'invoquer UserDTO.validate() à partir de ce validateur personnalisé au lieu de l'appeler depuis le service

Cela permettra de séparer votre logique de validation de la couche de service et de la rendre également portable et modulaire