Les validateurs dupliquent-ils la logique métier?

Question

Je sais qu'il est possible d'utiliser des validateurs pour vérifier l'entrée de données dans la couche de présentation d'une application (par exemple regex, champs obligatoires, etc.) et pour afficher un message et/ou une icône de marqueur requise. La validation des données appartient généralement à la couche de gestion. Comment éviter d'avoir à gérer deux ensembles de validations sur les données que je collecte?

EDIT: Je sais que la validation de la présentation est bonne, qu'elle informe l'utilisateur et qu'elle n'est pas infaillible. Il n'en demeure pas moins que je vérifie effectivement la même chose à deux endroits?

Answer 1

Oui et non.

Cela dépend de l'architecture de votre application. Nous supposerons que vous construisez une application à n-tier, puisque la grande majorité des applications de nos jours ont tendance à suivre ce modèle.

La validation dans l'interface utilisateur est conçue pour fournir une rétroaction immédiate à l'utilisateur final du système afin d'empêcher l'exécution de la fonctionnalité dans les niveaux inférieurs en premier lieu avec des entrées non valides. Par exemple, vous ne voulez même pas essayer de contacter le serveur Active Directory sans un nom d'utilisateur et un mot de passe pour tenter l'authentification. La validation à ce stade vous permet d'économiser du temps de traitement lors de l'instanciation d'un objet, de sa configuration et d'un aller-retour inutile sur le serveur pour apprendre quelque chose que vous pourriez facilement déterminer grâce à une simple inspection des données.

La validation dans vos bibliothèques de classes est une autre histoire. Ici, vous validez les règles métier.Bien que l'on puisse soutenir que la validation dans l'interface utilisateur et la validation dans les bibliothèques de classes sont les mêmes, j'aurais tendance à ne pas être d'accord. La validation des règles métier a tendance à être beaucoup plus complexe. Vos règles dans ce cas peuvent être plus nuancées et peuvent détecter des éléments qui ne peuvent pas être glanés via l'interface utilisateur. Par exemple, vous pouvez appliquer une règle qui stipule que l'utilisateur peut exécuter une méthode uniquement après que toutes les propriétés d'une classe ont été correctement initialisées et uniquement si l'utilisateur est membre d'un groupe d'utilisateurs spécifique. Ou, vous pouvez spécifier qu'un objet ne peut être modifié que s'il n'a pas été modifié depuis vingt-quatre heures. Ou, vous pouvez simplement spécifier qu'une valeur de chaîne ne peut pas être nulle ou vide. Dans mon esprit, cependant, un logiciel correctement conçu utilise un mécanisme commun pour appliquer DRY (si possible) à la fois de l'interface utilisateur et de la bibliothèque de classes. Dans la plupart des cas, c'est possible. (Dans de nombreux cas, le code est si trivial, ça ne vaut pas la peine.)

Answer 2

Je ne pense pas que la validation côté client (couche de présentation) soit réelle et utile; au contraire, il avertit simplement l'utilisateur des erreurs que la validation côté serveur (couche de gestion) trouvera. Je pense à cela comme un composant d'interface utilisateur plutôt qu'un utilitaire de validation réel, et en tant que tel, je ne pense pas que les deux viole DRY.

EDIT: Oui, vous faites la même action, mais pour des raisons entièrement différentes. Si votre seul objectif est le strict respect de DRY, alors vous ne voulez pas faire les deux. Cependant, en faisant les deux, alors que vous effectuez la même action, les résultats de cette action sont utilisés à des fins différentes (en validant l'information par rapport à notifier l'utilisateur d'un problème), et en effectuant deux fois la même action. dans des informations utiles à chaque fois.

Answer 3

Je pense qu'avoir de bonnes validations à la couche d'application permet de multiples avantages. 1. Facilite les tests unitaires 2. Vous pouvez ajouter plusieurs clients sans vous soucier de la cohérence des données.

La validation de l'interface utilisateur peut être utilisée comme outil pour fournir des temps de réponse rapides aux utilisateurs finaux.

Answer 4

Chaque couche de validation sert un objectif différent. La validation de l'interface utilisateur est utilisée pour rejeter la mauvaise entrée. La validation de la logique métier est utilisée pour effectuer la validation en fonction des règles métier.

Pour la validation de l'interface utilisateur, vous pouvez utiliser RequiredFieldValidators et d'autres validateurs disponibles dans le framework ASP.NET. Pour la validation métier, vous pouvez créer un moteur de validation qui valide l'objet. Cela peut être accompli en utilisant les attributs personnalisés.

Voici un article qui explique comment créer un cadre de validation à l'aide des attributs personnalisés:

http://highoncoding.com/Articles/424_Creating_a_Domain_Object_Validation_Framework.aspx