Validation côté client (validation dans les couches de présentation)

Conseil

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Même si la source de vérité est le modèle de domaine et, finalement, vous devez avoir la validation au niveau du modèle de domaine, la validation peut toujours être gérée au niveau du modèle de domaine (côté serveur) et de l’interface utilisateur (côté client).

La validation côté client est une excellente commodité pour les utilisateurs. Il permet de gagner du temps qu'ils auraient autrement passé à attendre un aller-retour au serveur qui pourrait retourner des erreurs de validation. En termes d’entreprise, même quelques fractions de secondes multipliées des centaines de fois par jour s’ajoutent à beaucoup de temps, de dépenses et de frustration. La validation simple et immédiate permet aux utilisateurs de travailler plus efficacement et de produire une meilleure qualité d’entrée et de sortie.

Tout comme le modèle d’affichage et le modèle de domaine sont différents, la validation de modèle de vue et la validation du modèle de domaine peuvent être similaires, mais servent un objectif différent. Si vous êtes préoccupé par DRY (le principe Ne pas répéter vous-même), considérez que dans ce cas la réutilisation du code peut également signifier le couplage, et dans les applications d’entreprise, il est plus important de ne pas coupler le côté serveur au côté client que de suivre le principe DRY.

Même lorsque vous utilisez la validation côté client, vous devez toujours valider vos commandes ou entrées DTOs dans le code du serveur, car les API serveur sont un vecteur d’attaque possible. En règle générale, faire les deux est votre meilleur pari, car si vous avez une application cliente, du point de vue de l’expérience utilisateur, il est préférable d’être proactif et de ne pas autoriser l’utilisateur à entrer des informations non valides.

Par conséquent, dans le code côté client, vous validez généralement les ViewModels. Vous pouvez également valider les DTO ou commandes de sortie du client avant de les envoyer aux services.

L’implémentation de la validation côté client dépend du type d’application client que vous générez. Il sera différent si vous validez des données dans une application web MVC avec la plupart du code dans .NET et une application web SPA avec le code de validation en JavaScript ou TypeScript.

Ressources additionnelles

Validation dans les applications ASP.NET Core

• Rick Anderson. Ajout de la validation
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

Validation dans les applications web SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• Validation du formulaire
  https://angular.io/guide/form-validation

• Validation. Documentation de Breeze.
  https://breeze.github.io/doc-js/validation.html

• Formulaires et composants d’entrée Blazor ASP.NET Core \ </aspnet/core/blazor/forms-and-input-components>

En résumé, il s’agit des concepts les plus importants en ce qui concerne la validation :

• Les entités et les agrégats doivent appliquer leur propre cohérence et être « toujours valides ». Les racines d’agrégation sont responsables de la cohérence multi-entité au sein du même agrégat.

• Si vous pensez qu’une entité doit entrer un état non valide, envisagez d’utiliser un autre modèle objet, par exemple en utilisant un DTO temporaire jusqu’à ce que vous créiez l’entité de domaine finale.

• Si vous devez créer plusieurs objets connexes, tels qu’un agrégat, et qu’ils ne sont valides qu’une fois tous ces objets créés, envisagez d’utiliser le modèle Factory.

• Dans la plupart des cas, la validation redondante côté client est bonne, car l’application peut être proactive.

précédentesuivante