C# Comment mettre en œuvre une méthode Save qui effectue des contrôles multiples ?

Question

Je suis souvent confronté à une méthode d'enregistrement qui doit vérifier un certain nombre de choses avant d'enregistrer dans la base de données.

Je vérifie, par exemple, les propriétés vides et les valeurs qui dépendent d'autres propriétés.

J'ai toujours du mal à savoir comment mettre en œuvre ce genre de choses. Les questions que je me pose sont les suivantes :

• Dois-je utiliser un booléen comme valeur de retour pour la méthode Save ? Et dans le code client, si l'on vérifie que c'est faux, on affiche à l'utilisateur final une boîte de message avec : "L'enregistrement a échoué". Mais le problème est que je ne peux pas montrer à l'utilisateur pourquoi l'enregistrement échoue. Je n'aime donc pas beaucoup celui-ci.
• Dans mes méthodes de sauvegarde, dois-je lancer une exception ? Ainsi, lorsqu'une vérification échoue, une exception est levée ?
• Ne rien faire. Lorsqu'une vérification échoue, ne faites rien. Mais je pense que ce n'est pas vraiment une option.

Je me demandais comment vous mettiez cela en œuvre. Existe-t-il une sorte de modèle ?

Answer 1

Ce n'est pas à la méthode de sauvegarde de valider l'objet. Il doit être valide lorsque la méthode Save est appelée. Il est donc normal de lancer une exception si l'objet n'est pas spécifié correctement.

En ce qui concerne la validation, il existe un cadre intégré dans .NET appelé DataAnnotations. Utilisez-le pour faciliter les validations dans toutes les couches.

Answer 2

Vous ne devez pas renvoyer de chaînes, mais lancer des exceptions. Vous pouvez créer des exceptions spécifiques telles que EmptyPropertyException, DateOutOfBoundException, etc. et les lancer. C'est maintenant au client d'attraper ces exceptions pour afficher les bons messages d'erreur. Il est préférable d'utiliser des exceptions car vous pouvez vouloir afficher des messages d'erreur légèrement différents à différents endroits ou utiliser des chaînes de caractères localisées.

Answer 3

Une très belle mise en œuvre est proposée par Enterprise Library - Validation block. Voir le niveau de détail et la facilité de mise en œuvre sur le site suivant :

http://msdn.microsoft.com/en-us/library/ff953192%28v=PandP.50%29.aspx

Answer 4

Cela dépend de vos besoins et de ceux des utilisateurs...
En gros, vous pourriez renvoyer une chaîne de caractères : si is null ou empty tout va bien, par contre cette chaîne est l'erreur. Vous pouvez donc afficher une MessageBox ou prendre n'importe quelle mesure.
En général, je préfère ne rien faire côté serveur (en cas d'erreur) et renvoyer l'erreur elle-même, de sorte que côté client, je puisse prendre des mesures ou laisser l'utilisateur décider de ce qu'il doit faire.
Vous pouvez même renvoyer une exception au serveur en cas d'erreur ou une valeur nulle si tout s'est bien passé.

Answer 5

Si vous voulez savoir pourquoi la sauvegarde a échoué, utilisez une exception : c'est leur raison d'être.