Erstellen fokussierter Domänenanwendungen. Ein Symfony-Ansatz (Verwaltung von Validierungsfehlern)

Einführung

Im letzten Beitrag haben wir analysiert, wie die Symfony-Komponenten des Serialisierers und Validators als Infrastrukturdienste fungierten und uns Tools zur Verfügung stellten, die uns bei der Ausführung allgemeiner Aufgaben in Anwendungen unterstützen. Wir haben auch erfahren, warum die Klasse UserInputDTO das Element war, das zu unserer Domäne gehörte, da sie Geschäftsregeln enthielt, und wie man einen Dienst auf Anwendungsebene erstellt, um den Datenfluss zu extrahieren und zu validieren.

In diesem zweiten Teil werden wir sehen, wie man mit Validierungsfehlern umgeht, und wie im ersten Teil werden wir identifizieren, welche Teile zur Domäne gehören.

Die Validierungsfehler

Die Validierungsfehler werden von der Symfony-Validierungskomponente zurückgegeben, nachdem das UserInputDTO gemäß den Regeln validiert wurde, die durch die Verwendung der Validierungsbeschränkungen festgelegt wurden.

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
}

Wie Sie im obigen Code sehen können, wird eine Ausnahme vom Typ ValidationException ausgelöst, wenn die Validierungsmethode Fehler findet. Von hier aus müssen wir entscheiden, wie wir die Fehler dem Benutzer anzeigen möchten (Domänen-/Geschäftsregeln) und auf welche Tools wir uns verlassen, damit die Fehler den Benutzer korrekt erreichen (Infrastruktur und Anwendung).

Zentralisierung der Erkennung von Validierungsfehlern

Das erste, was wir berücksichtigen müssen, ist, dass wir die Validierungsfehler abfangen wollen, wann immer sie auftreten. Um dies zu erreichen, werden wir auf die Infrastrukturschicht zurückgreifen.
Der Symfony-Kernel verfügt über eine Reihe integrierter Kernel-Ereignisse, um auf besondere Ereignisse zu warten. Eines dieser Ereignisse ist das Kernel-Ausnahmeereignis, das ausgelöst wird, wenn eine Ausnahme ausgelöst wird. Verwenden wir es zum Abfangen der ValidationException-Fehler.

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
        }
    }
}

Wie wir im obigen Code sehen können, lauscht der KernelSubscriber weiterhin auf das Ereignis KernelException und führt nur dann eine Logik aus, wenn die abgefangene Ausnahme eine Instanz von ValidationFailedException Klasse. Von hier aus müssen wir die Logik definieren, die ausgeführt wird, wenn die Methode
onException erkennt, dass es sich um einen Validierungsfehler handelt.

Erstellen eines Domänendienstes zum Erstellen des Fehlerarrays

Da wir für die Entscheidung verantwortlich sind, wie wir die Fehler strukturieren (wir definieren diese Geschäftsregeln), gehört der Dienst, der die Logik ausführt, zu unserer Domäne. Lass es uns codieren

class ValidationErrorsBuilder {

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

        return $errors;
    }
}

Der

ValidationErrorsBuilder-Code ist ziemlich einfach: Er durchläuft die Verstoßfehler und erstellt ein assoziatives Array, in dem die Schlüssel die Eigenschaften sind, die einen Fehler generiert haben, und die Werte die Fehlermeldungen.

Verwendung des ValidationErrorsBuilder

Jetzt ist es Zeit, unseren Domain-Service ValidationErrorsBuilder zu nutzen. Wir verwenden es auf der Methode 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
}

Wie Sie sehen können, verwenden wir unseren Domänendienst, um das Validierungsfehler-Array abzurufen, nachdem wir wissen, dass es sich bei der Ausnahme um eine ValidationFailedException handelt.
Sehen wir uns nun den folgenden Code an:

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
        }
    }
}

Wir haben eine neue Zeile hinzugefügt, in der wir eine Symfony JsonResponse festlegen, die das Fehlerarray als neue Antwort enthält, und wir geben an, dass der zurückgegebene HTTP-Code eine 400 Bad Request sein wird.
Wir haben uns auf die Konstante Symfony Response HTTP_BAD_REQUEST verlassen, um den Antwort-HTTP-Code anzugeben. Da wir in einer domänenorientierten Umgebung arbeiten, hätten wir unsere benutzerdefinierte Domänenklasse (z. B. eine PHP-Enumeration) erstellen können. Da wir jedoch nur Standard-HTTP-Codes verarbeiten müssen und kein besonderer Anpassungsbedarf besteht, können wir die verwenden Symfony-HTTP-Codes, obwohl wir dadurch etwas stärker vom Framework abhängig sind.

Und die Anwendungsschicht?

Über die Anwendungsschicht haben wir bisher noch nicht gesprochen. Wir haben am Anfang des Artikels gesagt, dass das Symfony-Framework über nützliche integrierte Ereignisse wie das von uns verwendete verfügt: Das Kernel-Ausnahmeereignis. Darüber hinaus bietet uns das Symfony-Framework auch das EventSubscriberInterface, mit dem wir unsere benutzerdefinierten Event-Abonnenten erstellen und die von uns benötigten Events anhören können.
Aus diesen Informationen können wir schließen, dass Symfony uns das Kernel-Ausnahmeereignis und das EventSubscriberInterface anbietet, aber wir müssen die Schnittstelle verwenden, um den Abonnenten zu erstellen und anzugeben, welche Ereignisse wir abhören werden. Lasst uns fortfahren:

• Der Ereignisabonnent gibt an, dass wir auf das Kernel-Exception-Ereignis hören.
• Der Ereignisabonnent prüft, ob die Ausnahme eine Instanz der ValidationFailedException ist.
• Der Ereignisabonnent verwendet den Domänendienst, um das Fehlerarray zu erstellen.
• Der Ereignisabonnent erstellt eine JsonResponse mit den Fehlern und legt sie als endgültige Antwort fest.

Kommt Ihnen das bekannt vor? Ja, der Ereignisabonnent ist für die Orchestrierung und Koordination der Verwaltung der Validierungsfehler verantwortlich, nachdem die Ausnahme ausgelöst wurde. Man könnte also sagen, dass der Ereignisabonnent als Anwendungsdienst fungiert.
Wenn wir noch einen Schritt weiter gehen möchten, könnten wir einen Anwendungsschichtdienst erstellen und ihn im Abonnenten verwenden.

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);
    }
}

Jetzt würde der ValidationErrorsProcessor als Anwendungsdienst fungieren, der das Antwortmanagement für Validierungsfehler koordiniert und den Domänendienst ValidationErrorsBuilder verwendet.

Abschluss

In diesem zweiten Artikel dieser Serie haben wir identifiziert, welche Komponenten des Validierungsfehlermanagementprozesses zur Domäne gehören, welche Elemente der Infrastruktur wir verwendet haben und wie der Kernel-Abonnent als Anwendungsdienst fungieren kann.
Im nächsten Artikel werden wir die Entität in der Datenbank beibehalten und analysieren, wie wir die Logik der Umwandlung des DTO in eine persistente Entität trennen können.

Das obige ist der detaillierte Inhalt vonErstellen fokussierter Domänenanwendungen. Ein Symfony-Ansatz (Verwaltung von Validierungsfehlern). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!