Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Tipp
Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.
Selbst wenn die Quelle der Wahrheit das Domänenmodell ist und schließlich eine Validierung auf der Ebene des Domänenmodells erforderlich ist, kann die Validierung dennoch sowohl auf der Ebene des Domänenmodells (serverseitig) als auch auf der Benutzeroberfläche (clientseitig) durchgeführt werden.
Die clientseitige Überprüfung ist ein hervorragender Komfort für Benutzer. Es spart Zeit, die sie sonst mit dem Warten auf eine Hin- und Rückfahrt zum Server verbringen würden, der Validierungsfehler zurückgeben kann. Aus geschäftlicher Sicht summieren sich einige Bruchteile von Sekunden, die täglich hunderte Male auftreten, zu einer Menge an Zeit, Kosten und Frustration. Eine einfache und sofortige Validierung ermöglicht es Benutzern, effizienter zu arbeiten und eine bessere Qualität der Eingabe und Ausgabe zu erzielen.
Ebenso wie das Ansichtsmodell und das Domänenmodell unterschiedlich sind, kann die Überprüfung des Ansichtsmodells und die Domänenmodellüberprüfung ähnlich sein, dient jedoch einem anderen Zweck. Wenn Sie sich Sorgen um DRY (das Prinzip "Don't Repeat Yourself") machen, beachten Sie, dass die Wiederverwendung von Code in diesem Fall auch eine Kopplung bedeuten könnte. Daher ist es in Unternehmensanwendungen wichtiger, die Serverseite nicht an die Clientseite zu koppeln, als dem DRY-Prinzip zu folgen.
Selbst bei verwendung der clientseitigen Überprüfung sollten Sie ihre Befehle oder Eingabe-DTOs immer im Servercode überprüfen, da die Server-APIs ein möglicher Angriffsvektor sind. In der Regel ist beides Ihre beste Wahl, denn wenn Sie eine Clientanwendung haben, ist es aus einer UX-Perspektive am besten, proaktiv zu handeln und dem Benutzer nicht zu erlauben, ungültige Informationen einzugeben.
Daher überprüfen Sie in clientseitigem Code normalerweise die ViewModels. Sie können auch die Ausgabe-DTOs oder -befehle des Clients überprüfen, bevor sie an die Dienste gesendet werden.
Die Implementierung der clientseitigen Überprüfung hängt davon ab, welche Art von Clientanwendung Sie erstellen. Dies unterscheidet sich, wenn Sie Daten in einer MVC-Webanwendung mit den meisten Code in .NET im Vergleich zu einer SPA-Webanwendung mit dem Überprüfungscode in JavaScript oder TypeScript überprüfen.
Weitere Ressourcen
Überprüfung in ASP.NET Core-Apps
-
Überprüfung hinzufügen
https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation
Überprüfung in SPA Web Apps (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)
Form Validation (Formularüberprüfung)
https://angular.io/guide/form-validationValidierung. Breeze-Dokumentation
https://breeze.github.io/doc-js/validation.htmlASP.NET Core Blazor Formulare und Eingabekomponenten \ </aspnet/core/blazor/forms-and-input-components>
Zusammenfassend sind dies die wichtigsten Konzepte in Bezug auf die Validierung:
Entitäten und Aggregate sollten ihre eigene Konsistenz erzwingen und "immer gültig" sein. Aggregatwurzeln sind für die Konsistenz von mehreren Entitäten innerhalb desselben Aggregats verantwortlich.
Wenn Sie der Meinung sind, dass eine Entität einen ungültigen Zustand eingeben muss, erwägen Sie die Verwendung eines anderen Objektmodells, z. B. die Verwendung eines temporären DTO, bis Sie die endgültige Domänenentität erstellen.
Wenn Sie mehrere verwandte Objekte erstellen müssen, z. B. ein Aggregat, und sie sind nur gültig, nachdem alle objekte erstellt wurden, sollten Sie das Factory-Muster verwenden.
In den meisten Fällen ist die redundante Überprüfung auf der Clientseite gut, da die Anwendung proaktiv sein kann.