Où faites-vous votre validation? modèle, contrôleur ou vue
https://stackoverflow.com/questions/134388
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Où placez-vous la validation des entrées utilisateur dans une application de formulaire Web?
- Vue: côté client JavaScript
- Contrôleur: langage côté serveur (C # ...)
- Modèle: Base de données (procédures stockées ou dépendances)
Je pense qu'une validation est requise pour chaque niveau:
- l'utilisateur at-il entré une valeur saine?
- sont les dates les dates réelles, les nombres sont-ils les chiffres ...
- Effectuez toutes les vérifications dans 1. à nouveau plus les vérifications d'attaques malveillantes (injection IE XSS ou SQL)
- Les vérifications effectuées dans 1. servent principalement à éviter un aller-retour de serveur lorsque l'utilisateur commet une erreur.
- Comme elles sont effectuées côté client en javascript, vous ne pouvez pas avoir confiance qu'elles ont été exécutées. Valider à nouveau ces valeurs arrêtera certaines attaques malveillantes.
- Les dépendances sont-elles respectées (l'utilisateur a-t-il ajouté un commentaire à une question valide)?
- Une bonne interface les rend très difficiles à violer. Si quelque chose est pris ici, quelque chose a très mal tourné.
[inspiré par cette réponse ]
La solution
Je vérifie tous les niveaux, mais j'aimerais noter une astuce de validation que j'utilise.
Je valide dans la couche base de données, les contraintes appropriées sur votre modèle fourniront une validation automatique de l'intégrité des données.
C’est un art qui semble être perdu pour la plupart des programmeurs Web.
Autres conseils
Validation dans le modèle, éventuellement des routines automatisées dans l'interface utilisateur qui s'inspirent du modèle et améliorent l'expérience utilisateur.
Par routines automatisées, je veux dire qu’il ne devrait y avoir aucun code de validation par modèle dans l’interface utilisateur. Si vous avez une bibliothèque de méthodes de validation, telle que RoR (qui a des méthodes telles que validates_presence_of: nom d'utilisateur), le contrôleur ou la vue devrait pouvoir les lire et appliquer des méthodes javascript équivalentes (ou ce qui est pratique).
Cela signifie que vous devrez dupliquer la bibliothèque de validation complète dans l'interface utilisateur, ou au moins fournir un mappage si vous en utilisez un déjà existant. Mais une fois que cela est fait, vous n’aurez plus à écrire de logique de validation en dehors du modèle.
La validation peut être effectuée à toutes les couches.
La validation de l'entrée à partir d'un formulaire Web (toutes les chaînes, la conversion en types appropriés, etc.) diffère de la validation de l'entrée à partir d'un service Web, d'un fichier XML, etc. Chacune a ses propres cas particuliers. Vous pouvez bien sûr créer une classe d'assistance Validator, ce qui permet d'externaliser la validation et de la partager avec les vues.
Ensuite, vous avez la validation de la couche DAO - le modèle contient-il suffisamment de données pour persister (pour respecter les contraintes non nulles, etc.), etc. Vous pouvez même avoir des contraintes de vérification dans la base de données (son statut est indiqué dans ('N', 'A', 'S', 'D') etc.).
Ceci est intéressant. Pendant très longtemps, j'ai effectué toutes les validations dans le modèle, juste au-dessus de ce que je considérerais comme DAL (couche d'accès aux données). Mes modèles sont généralement configurés après la passerelle de données de table avec une liste DAL fournissant l’abstraction et l’API de bas niveau.
À côté du TMD, je mettrais en œuvre la logique métier et les validations, telles que:
- Le nom d'utilisateur est-il vide
- est nom d'utilisateur > 30 caractères
- Si l'enregistrement n'existe pas, renvoyer l'erreur
Au fur et à mesure que mon application devenait de plus en plus complexe, j'ai commencé à comprendre qu'une grande partie de la validation pouvait être effectuée côté client, à l'aide de JavaScript. J'ai donc refactoré la majeure partie de la logique de validation dans JS et nettoyé mes modèles.
Ensuite, je me suis rendu compte que la validation côté serveur (sans filtrage ni échappement - ce que je considère comme différent) devrait probablement être effectuée sur le serveur également et uniquement côté client comme une cerise sur le gâteau.
La logique de validation a donc été inversée lorsque je me suis rendu compte à nouveau qu'il existait probablement une différence nette entre la validation / assertion INPUT et les règles / logique commerciales.
Fondamentalement, si cela peut être fait dans la partie client de l’application (avec JS), j’estime qu’il s’agit d’une validation INPUT ... si cela DOIT être fait par le modèle (cet enregistrement existe-t-il déjà, etc.?). considérerait cette logique métier. Ce qui est déroutant, c’est que les deux protègent l’intégrité du modèle de données.
Si vous ne validez pas la longueur d'un nom d'utilisateur, comment empêcher les utilisateurs de créer un nom d'utilisateur composé d'un seul caractère?
Je n'ai pas encore tout à fait décidé où placer cette logique, je pense que cela dépend vraiment de ce que vous préférez, contrôleurs minces, modèles lourds ou inversement ...
Dans mon cas, les contrôleurs ont tendance à être beaucoup plus centrés sur les applications, alors que les modèles, s'ils sont conçus avec soin, peuvent souvent être réutilisés dans "autre". projets non seulement en interne, je préfère donc garder les modèles légers et les contrôleurs plus lourds.
Ce qui vous pousse dans les deux sens, ce sont les opinions personnelles, les exigences, les expériences, etc.
Sujet intéressant:)
La validation doit être effectuée dans le contrôleur. C’est le seul endroit qui assure la sécurité et la réactivité.
La validation devrait être effectuée dans la vue. Elle constitue le point de contact. Elle fournit le meilleur UE et enregistre les travaux supplémentaires de votre serveur.
La validation sera effectuée sur le modèle, mais uniquement pour un certain niveau de contrôle. Les bases de données doivent toujours refléter les contraintes appropriées, mais il est inefficace de laisser cela comme une véritable validation. Il n'est pas non plus possible pour une base de données de déterminer une entrée valide avec des contraintes simples.
Toutes les validations doivent avoir lieu au moins une fois, et cela doit se situer au niveau intermédiaire, que ce soit dans vos objets de valeur (au sens DDD, à ne pas confondre avec les DTO), ou via l'objet métier de l'entité. lui-même. La validation côté client peut avoir lieu pour améliorer l'expérience utilisateur. J'ai tendance à ne pas effectuer de validation côté client, car je peux simplement exposer en même temps toutes les erreurs sur le formulaire, mais ce n'est que ma préférence personnelle. le niveau intermédiaire ou arrière a terminé quelque chose.
Je ne le fais que dans la vue et le contrôleur, la base de données impose une partie de cela en fonction de vos types de données, mais je préférerais que cela n'aille pas aussi loin sans que je ne détecte une erreur.
Vous avez à peu près répondu à votre propre question, mais il est important de savoir que vous ne pouvez jamais faire confiance à la vue, bien que ce soit la voie la plus facile pour donner un retour à l'utilisateur. Vous devez donc préciser au moins un niveau supplémentaire.
Hmmmm, pas sûr. J'aurais dit le contrôleur jusqu'à ce que je lis cet article re: contrôleurs maigres, gros modèles
Étant donné que la plupart des validations dépendent de règles métier , je fais la validation sur la couche métier en tant que classes d'outils tierces. Il existe d'autres types de validations, telles que les entrées utilisateur, alors qu'elles doivent être effectuées dans le contrôleur, mais vous pouvez également encapsuler ces règles de validation dans des classes tierces. Vraiment, cela dépend de ce qu'il faut valider.
Les validations côté client sont les mineures. Elles sont juste destinées à créer une validation d’entrée légère, mais la validation côté serveur est obligatoire toujours . Vous ne pouvez jamais faire confiance à la saisie de l'utilisateur;)
.NET dispose de contrôles intéressants pour la création de validations, mais la couche métier a toujours besoin d'une meilleure approche pour valider les données et ces contrôles ne suffisent pas à cette tâche.
Validation simple des entrées dans la vue. Validation complète dans le modèle. Raison? Si vous changez de technologie d'affichage et que la validation se trouve dans la vue / le contrôleur, vous devez réécrire votre validation pour la nouvelle vue. Cela peut introduire des bugs. Mettez-le dans le modèle, et cela sera réutilisé par toutes les vues ...
Mais, comme je l'ai dit, une validation simple dans la vue pour la rapidité et la facilité.
