Discussion :

[NoPr0n]

Bonjour à tous

Je travaille sur un projet d'assez grosse envergure et je recherche la bonne pratique pour factoriser proprement un service. Je suis dans le cas de figure suivant :
J'ai un webservice qui me permet de créer des "commandes" (liste des articles, adresses, montant de la commande etc). Avant de sauvegarder la commande en base de donnée je dois effectuer une série de validation et également récupérer des données en base de donnée.
Par exemple, je dois vérifier que l'id d'article passé en paramètre correspond bien à un article existant et je dois récupérer l'objet "Article" pour pouvoir effectuer d'autres traitement plus tard dans le processus (décrémenter le stock, etc ...).

Mais question est donc : Quel serait le moyen le plus propre de factoriser ma méthode de récupération/validation de données ? Sachant que ma méthode mère à besoin d'avoir accès aux objets récupérés mais également à un "code erreur" pour pouvoir retourner le problème au client du Webservice.
J'ai pensé à plusieurs solutions mais aucune ne me parait idéale :
- Gérer toutes les erreurs avec des exceptions : J'ai peur que ça devienne un enfer de try-catch
- Retourner le code erreur en retour de fonction et l'objet via un paramètre d'entré de la fonction passé en référence : Bof ?
- Créer deux méthodes, une pour la récupération et une pour la validation : Une partie du code va être dupliquée. Je vais devoir refaire les requêtes en BDD et donc doubler la charge.

Voilà, aucune de ces solutions ne me semble idéale. Qu'en pensez vous ? Avez vous d'autres solutions à proposer ?

[mathieu]

par rapport aux 3 propositions, j'ai l'impression que la 1re a l'air la plus efficace.
par contre, je ne comprends pas ce qui vous gênes avec les "try-catch", j'ai l'impression qu'il y aura un seul "try" au niveau de la construction de la réponse avec une exception spéciale "DonneesInvalidesException" et donc si une telle exception est lancée à n'importe quelle niveau, l'exception contiendra un code d'erreur ainsi qu'éventuellement un message pour aider à la résolution.
donc si je n'ai rien loupé, il ne devrait pas y avoir plusieurs "try", si ?

[NoPr0n]

Ce n'est absolument pas clair dans mon premier message mais ce qui me gène un peu avec les exceptions c'est que je vais avoir des cas ou les erreurs de validations sont non-bloquantes. Par exemple si l'adresse n'est pas bien formatée, je continue à sauvegarder/valider ma commande mais je la "bloque" en attendant qu'un administrateur puisse corriger les données manuellement.
Hors si je lève une exception dans une méthode ça va forcément la terminer.
Idéalement il faudrait également que je "stocke" localement dans la méthode parente la liste des erreurs non-bloquantes pour pouvoir, par exemple, envoyer un retour webservice au client pour l'avertir des différentes erreurs survenues lors du traitement.

Je pense que je peux gérer les erreurs bloquantes avec des exceptions mais il me faut une solution alternative et maintenable pour les erreurs non bloquantes.

[mathieu]

pour reprendre l'exemple de l'adresse, si la fonctionnalité est de faire valider l'adresse par un administrateur, le cahier des charges prévoit donc que l'adresse ait un état "valide / en attente de validation". donc l'envoi d'une requête d'ajout d'adresse peut retourner une réponse classique "adresse enregistrée" avec éventuellement l'identifiant du nouvel objet et le valeur de son état "valide / en attente de validation".
en revanche si la requête est la demande d'une adresse avec un identifiant qui n'existe pas, je suppose qu'on est clairement en dehors des fonctionnalités prévues et donc cela produit une exception avec arrêt du traitement et retour d'un code d'erreur en réponse.