Création d'applications de domaine ciblées. Une approche Symfony (Gestion des erreurs de validation)

Introduction

Dans le dernier article, nous avons analysé comment les composants Symfony du sérialiseur et du validateur agissaient comme des services d'infrastructure nous fournissant des outils qui nous aident à effectuer des tâches courantes dans les applications. Nous avons également appris pourquoi la classe UserInputDTO était l'élément qui appartenait à notre domaine puisqu'elle contenait des règles métier et comment créer un service de couche d'application pour effectuer l'extraction et la validation du flux de données.

Dans cette deuxième partie, nous allons voir comment gérer les erreurs de validation et, comme nous l'avons fait dans la première partie, nous identifierons quelles parties appartiennent au domaine.

Les erreurs de validation

Les erreurs de validation sont renvoyées par le composant validateur Symfony après validation du UserInputDTO suivant les règles établies en utilisant les contraintes de validation.

public function processData(string $content, string $dtoClass): object
{
     $requestData = json_decode($content, true);
     $userInputDTO = $serializer->denormalize($requestData, UserInputDTO::class);
     $errors = $validator->validate($userInputDTO);
     if(count($errors) > 0) {
         throw new ValidationFailedException($errors);
     }

     return $userInputDTO
}

Comme vous pouvez le voir dans le code ci-dessus, si la méthode de validation trouve des erreurs, une exception du type ValidationException est levée. À partir de là, nous devons décider comment nous voulons montrer les erreurs à l'utilisateur (domaine / règles métier) et sur quels outils nous nous appuierons pour que les erreurs parviennent correctement à l'utilisateur (infrastructure et application).

Centraliser la capture des erreurs de validation

La première chose que nous devons prendre en compte est que nous voulons détecter les erreurs de validation chaque fois qu'elles se produisent. Pour y parvenir, nous nous appuierons sur la couche infrastructure.
Le noyau Symfony est livré avec un ensemble d'événements de noyau intégrés pour écouter les événements spéciaux. L'un de ces événements est l'événement d'exception du noyau qui est déclenché lorsqu'une exception est levée. Utilisons-le pour détecter les erreurs ValidationException.

class KernelSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::EXCEPTION => 'onException'
        ];
    }

    public function onException(ExceptionEvent $event): void
    {
        $exception = $event->getThrowable();
        if($exception instanceof ValidationFailedException){
            // Business rules to build the errors
        }
    }
}

Comme nous pouvons le voir dans le code ci-dessus, le KernelSubscriber continue d'écouter l'événement KernelException et il n'exécutera une certaine logique que lorsque l'exception interceptée est une instance de ValidationFailedException. A partir de là, il faut définir la logique qui sera exécutée lorsque la méthode
onException détecte qu'il s'agit d'une erreur de validation.

Création d'un service de domaine pour construire le tableau des erreurs

Comme nous sommes en charge de décider comment nous allons structurer les erreurs (nous définissons ces règles métier), le service qui exécute la logique appartiendra à notre domaine. Codons-le

class ValidationErrorsBuilder {

    public function buildErrors(ValidationFailedException $exception): array
    {
        $errors = [];
        foreach ($exception->getViolations() as $violation) {
            $errors[$violation->getPropertyPath()] = $violation->getMessage();
        }

        return $errors;
    }
}

Le code

ValidationErrorsBuilder est assez simple : il boucle les erreurs de violation et crée un tableau associatif où les clés sont les propriétés qui ont généré une erreur et les valeurs sont les messages d'erreur.

Utilisation du ValidationErrorsBuilder

Il est maintenant temps d'utiliser notre service de domaine ValidationErrorsBuilder. Nous l'utilisons sur la méthode KernelSubscriber onException.

public function processData(string $content, string $dtoClass): object
{
     $requestData = json_decode($content, true);
     $userInputDTO = $serializer->denormalize($requestData, UserInputDTO::class);
     $errors = $validator->validate($userInputDTO);
     if(count($errors) > 0) {
         throw new ValidationFailedException($errors);
     }

     return $userInputDTO
}

Comme vous pouvez le voir, après avoir su que l'exception est une ValidationFailedException, nous utilisons notre service de domaine pour obtenir le tableau des erreurs de validation.
Voyons maintenant le code suivant :

class KernelSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::EXCEPTION => 'onException'
        ];
    }

    public function onException(ExceptionEvent $event): void
    {
        $exception = $event->getThrowable();
        if($exception instanceof ValidationFailedException){
            // Business rules to build the errors
        }
    }
}

Nous avons ajouté une nouvelle ligne où nous définissons une Symfony JsonResponse contenant le tableau d'erreurs comme nouvelle réponse et nous spécifions que le code HTTP renvoyé sera une 400 Bad Request.
Nous nous sommes appuyés sur la constante Symfony Response HTTP_BAD_REQUEST pour spécifier le code HTTP de la réponse. Comme nous travaillons dans un environnement axé sur le domaine, nous aurions pu créer notre classe de domaine personnalisée (par exemple une énumération php) mais, comme nous n'avons besoin de gérer que les codes HTTP standard et qu'il n'y a pas de besoin spécifique de personnalisation, nous pouvons utiliser le Codes HTTP Symfony même si cela nous fait dépendre un peu plus du framework.

Et la couche application ?

Nous n’avons pas parlé de la couche application jusqu’à présent. Nous avons dit au début de l'article que le framework Symfony est livré avec un événement intégré utile tel que celui que nous avons utilisé : L'événement d'exception du noyau. De plus, le framework symfony nous offre également la EventSubscriberInterface grâce à laquelle nous pouvons créer nos abonnés aux événements personnalisés et écouter les événements dont nous avons besoin.
De ces informations, nous pouvons conclure que symfony nous propose l'événement d'exception du noyau et la EventSubscriberInterface mais nous devons utiliser l'interface pour créer l'abonné en précisant quels événements nous allons écouter. Reprenons :

• L'abonné à l'événement précise que nous écoutons l'événement Kernel Exception.
• L'abonné à l'événement vérifie si l'exception est une instance de ValidationFailedException.
• L'abonné à l'événement utilise le service de domaine pour créer le tableau d'erreurs.
• L'abonné à l'événement crée un JsonResponse contenant les erreurs et le définit comme réponse finale.

Cela vous semble familier ? Oui, l'abonné à l'événement est responsable de l'orchestration et de la coordination de la gestion des erreurs de validation après la levée de l'exception. On pourrait donc dire que l'abonné à l'événement agirait comme un service d'application.
Si nous voulons aller plus loin, nous pourrions créer un service de couche application et l'utiliser chez l'abonné.

class ValidationErrorsBuilder {

    public function buildErrors(ValidationFailedException $exception): array
    {
        $errors = [];
        foreach ($exception->getViolations() as $violation) {
            $errors[$violation->getPropertyPath()] = $violation->getMessage();
        }

        return $errors;
    }
}

public function onException(ExceptionEvent $event): void
{
    $exception = $event->getThrowable();
    if($exception instanceof ValidationFailedException){
       $errors = $this->validationErrorsBuilder->buildErrors($exception);
    }
}

Désormais, le ValidationErrorsProcessor agirait comme un service d'application coordonnant la gestion des réponses aux erreurs de validation et utilisant le service de domaine ValidationErrorsBuilder.

Conclusion

Dans ce deuxième article de cette série, nous avons identifié quels composants du processus de gestion des erreurs de validation appartiennent au domaine, quels éléments de l'infrastructure nous avons utilisés et comment l'abonné Kernel peut agir en tant que service applicatif.
Dans le prochain article, nous persisterons l'entité dans la base de données et nous analyserons comment séparer la logique de transformation du DTO en une entité persistable.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!