Où faites-vous la validation dans une application web (backend)?

Question

Où faites-vous la validation dans une application web (backend)?

Option 1: Couche de service?

UserService.validate(FORM); // verify and returns struct of errors 

Option # 2: couche d'objets, sur setter? par exemple.

user.setEmail(email); // throws invalid/used e-mail 

Option # 3: couche d'objet, valider()? par exemple.

user.init(FORM); // accept any values, no type checking 
user.validate(); // returns struct of errors 

Quelle est votre opinion? Merci!

Answer 1

Je conserve généralement ma validation de formulaire dans la couche de service, plutôt qu'avec les objets eux-mêmes. Je ne le fais pas parce que je ne suis pas d'accord avec le fait que les objets soient entièrement encapsulés, je le fais parce que cela correspond à la méthodologie/design que j'ai choisi dans mes sites pour gérer les soumissions de formulaires.

Je pense que les frameworks comme Transfer vous encouragent à conserver la validation des objets dans les objets où les moteurs/frameworks comme Alegad's Validat sont conçus pour garder la validation en dehors de celui-ci. Je ne pense pas que l'une ou l'autre approche soit fausse, c'est vraiment juste une question de ce que vous préférez (et de ce qui convient à l'application). Cependant, sur l'une des trois options, l'option n ° 2 est l'utilisation abusive de la gestion des exceptions pour les situations dans lesquelles vous avez des résultats attendus. En ayant une méthode de validation (que ce soit sur l'objet ou dans un service), vous pouvez contrôler les situations de validation erronées plus gracieusement que de capturer des exceptions et les faire bouillir passivement (capturer et renvoyer une structure avec des informations sur l'échec) ou explicitement , ect ..).

Answer 2

Vous effectuez une validation à chaque phase, mais pour des raisons légèrement différentes.

Vous validez lorsque l'utilisateur définit une valeur afin de fournir un retour immédiat à l'utilisateur pour savoir si l'entrée est valide. Cette validation ne devrait être utilisée que pour améliorer l'expérience de l'utilisateur. Vous pouvez valider pendant que l'utilisateur tape, si cela est approprié, mais assurez-vous de ne pas empêcher l'utilisateur d'entrer une entrée partielle non valide, car il pourrait y avoir plus de choses à venir et vous ne voulez pas que la validation soit gênante.

Vous validez avant que l'utilisateur soumette le formulaire afin de s'assurer que la soumission sera valide sans encourir le coût en temps d'un aller-retour complet au serveur. Ce serait principalement pour les choses qui n'ont pas été ou ne pouvaient pas être validées lors de la saisie de l'utilisateur, et cela pourrait impliquer une certaine communication avec le serveur, pour vérifier si un nom d'utilisateur est disponible par exemple, sans recharger la page. Cette étape est également principalement pour le bénéfice de l'utilisateur. Que vous validiez chaque élément lors de la saisie ou de l'envoi dépende de vous et dépende de ce qui offre une meilleure expérience utilisateur et correspond mieux au modèle mental de l'utilisateur. Enfin, vous devez tout valider quand il revient au serveur car vous ne pouvez pas faire confiance au navigateur. Cette validation est principalement pour la sécurité. Vous ne pouvez jamais supposer que les données provenant de votre client sont propres, car elles ne proviennent peut-être pas de votre client. Cela peut provenir d'un agent hostile qui émule votre client. Donc, tout valider, complètement, pour tous les exploits potentiels et autres conditions invalides, indépendamment du fait qu'il a été validé dans le client.

Espérons que ça aide.

Answer 3

Tout d'abord, +1 de moi pour jborque.

Je voudrais ajouter que les validations de type d'entrée sont très répétitives, par ex.

UI: Ne pas laisser nom à plus de 30 caractères BIZ: Lancer une exception/créer enfreint la règle si le nom est plus de 30 caractères DB: Faire colonne Nom 30 caractères TEST UNITÉ: Les noms de test < 30,> 30, exactement 30 caractères de long

Ceci est un excellent candidat pour la génération de code. Si 30 passe brusquement à 40 et que vous utilisez la génération de code, la modification est aussi simple que la réexécution du générateur de code (et la création de scripts de mise à niveau DB pour toutes les données de production). Je l'ai fait par le passé en utilisant un outil de modélisation UML pour capturer des règles d'entrée et des classes partielles en C# pour séparer le code généré du modèle UML de mon propre code écrit à la main.Le même concept peut être appliqué facilement dans un certain nombre d'environnements de développement.

Answer 4

+1 pour jbourqu aussi. Belles réponses. Partout où vous pouvez sans encourir des coûts de performance déraisonnables. Je valide assez souvent les entrées de fonctions dans le backend qui ne sont pas directement exposées au cas où un autre code les appelle avec des valeurs inattendues ou mélange l'ordre des paramètres.