Défauts WCF avec SOAP

Question

Je ne comprends pas comment renvoyer les erreurs à un client utilisant SOAP.

J'ai un service wcf, mais je ne suis pas sûr de la technologie utilisée par le client. J'aimerais donc rester fidèle à la spécification SOAP.

D'après ce que j'ai lu, les messages d'erreur semblent être le meilleur moyen de gérer cela.

Je vois que mon service présente de nombreux défauts différents:

• Null \ erreurs de données attendues
• Erreurs de format de données (c.-à-d. que la base de données n'autorise que 3 caractères)
• Erreurs de plage de données "Le client existe déjà", "Impossible de traiter votre demande". erreurs de type

Serait-il approprié de créer un nouvel objet pour chacune de ces fautes et de lancer comme tel:

FaultException<NullFault>(nf);  
FaultException<InvalidDataFault>(idf);  
FaultException<ArguementFault>(af);  
FaultException<RangeFault>(rf);  

Le client transmet des objets volumineux comportant de nombreuses propriétés à pratiquement toutes les méthodes. (ex: client, commande, etc.).

Serait-ce le moyen approprié pour gérer les erreurs et les renvoyer au client?

Il semble déplacé d'ajouter chaque erreur aux attributs situés au-dessus de la méthode.

IE:

[OperationContract]  
[FaultContract(typeof(NullFault))]  
[FaultContract(typeof(InvalidDataFault))]  
[FaultContract(typeof(ArguementFault))]  
[FaultContract(typeof(RangeFault))]  
void CreateCustomer(Customer customer);  

Aussi, qu'en est-il d'un GenericFault? Comment géreriez-vous les erreurs de règles métier? Par exemple, le client existe déjà, trop d’éléments de campagne, ne sont pas livrés dans cette zone, le mode de paiement n’est pas accepté, etc.?

Faites-moi savoir si cette méthode est appropriée ou s'il existe une autre solution acceptée et comment vous traiteriez la situation de la "règle de gestion".

Answer 1

En règle générale, renvoyer une erreur est la bonne façon de le faire, mais vous devriez également vous demander ce que le programme client va faire avec les informations que vous retournez dans une erreur. Si le client a seulement besoin de savoir qu’un défaut est survenu, il ne vous faut plus qu’un seul défaut. Cette erreur pourrait inclure le texte du message que le client pourrait afficher à son utilisateur.

Si le client doit prendre des mesures différentes, qu'il s'agisse d'un défaut NullFault ou d'un RangeFault, vous devez définir des erreurs distinctes. Mais s’il n’ya pas de différence, épargnez-vous, vous-même et les programmes clients, et ne définissez qu’une faute.