WCF - Défauts / Exceptions versus Messages

Question

Nous discutons actuellement pour savoir s'il vaut mieux jeter les erreurs sur un canal WCF, par opposition à un message indiquant le statut ou la réponse d'un service.

Les erreurs sont fournies avec le support intégré de WCF où vous pouvez utiliser les gestionnaires d’erreur intégrés et réagir en conséquence. Cela entraîne toutefois des frais généraux, car le lancement d’exceptions dans .NET peut être très coûteux.

Les messages peuvent contenir les informations nécessaires pour déterminer ce qui s'est passé avec votre appel de service sans la surcharge de générer une exception. Toutefois, il a besoin de plusieurs lignes de code répétitif pour analyser le message et déterminer les actions à suivre.

Nous avons essayé de créer un objet de message générique que nous pourrions utiliser dans nos services. Voici ce que nous avons proposé:

public class ReturnItemDTO<T>
{
    [DataMember]
    public bool Success { get; set; }

    [DataMember]
    public string ErrorMessage { get; set; }

    [DataMember]
    public T Item { get; set; }
}

Si tous mes appels de service renvoient cet élément, je peux toujours cocher la case "Succès". propriété pour déterminer si tout s’est bien passé. J'ai alors une chaîne de message d'erreur dans l'événement indiquant une anomalie, ainsi qu'un élément générique contenant un Dto si nécessaire.

Les informations sur l'exception devront être déconnectées d'un service de journalisation central et ne pas être renvoyées du service.

Des pensées? Commentaires? Des idées? Suggestions?

Des éclaircissements supplémentaires sur ma question

Un problème que je rencontre avec les contrats par défaut est la communication des règles commerciales.

Par exemple, si quelqu'un se connecte et que son compte est verrouillé, comment puis-je le communiquer? Leur connexion échoue évidemment, mais pour la raison "Compte verrouillé".

Moi aussi:

A) utiliser un booléen, jeter Fault avec le compte de message verrouillé

B) renvoyez AuthenticatedDTO avec les informations pertinentes

Answer 1

  

Toutefois, cela entraîne des frais généraux, car les exceptions générées dans .NET peuvent être très coûteuses.

Vous sérialisez et désérialisez des objets en XML et les envoyez sur un réseau lent. La surcharge résultant de la génération d'une exception est négligeable comparée à celle.

Je persiste généralement dans les exceptions, car elles communiquent clairement que quelque chose a mal tourné et tous les outils de service Web ont un bon moyen de les gérer.

Dans votre exemple, je lève une exception UnauthorizedAccessException avec le message "Compte verrouillé".

Clarification: Les services .NET wcf traduisent les exceptions en FaultContracts par défaut, mais vous pouvez modifier ce comportement. MSDN: spécification et gestion des erreurs dans les contrats et les services

Answer 2

Si vous envisagez d'appeler le service comme toute autre méthode, vous pourrez peut-être mettre les choses en perspective. Imaginez si chaque méthode que vous avez appelée renvoyait un statut et que vous deviez vérifier si elle était vraie ou fausse. Cela deviendrait assez fastidieux.

result = CallMethod();
if (!result.Success) handleError();

result = CallAnotherMethod();
if (!result.Success) handleError();

result = NotAgain();
if (!result.Success) handleError();

C’est l’un des points forts d’un système structuré de traitement des erreurs, c’est que vous pouvez séparer votre logique réelle de votre traitement des erreurs. Vous n'avez pas besoin de continuer à vérifier, vous savez que ce fut un succès si aucune exception n'a été levée.

try 
{
    CallMethod();
    CallAnotherMethod();
    NotAgain();
}
catch (Exception e)
{
    handleError();
}

En même temps, en renvoyant un résultat, vous responsabilisez davantage le client. Vous savez peut-être qu'il faut rechercher les erreurs dans l'objet résultat, mais John Doe arrive et commence tout simplement à appeler votre service, oubliant que tout est faux, car aucune exception n'est levée. Une autre grande force des exceptions est qu’elles nous offrent une bonne gifle quand quelque chose ne va pas et qu’il faut en prendre soin.

Answer 3

J'envisagerais sérieusement d'utiliser les objets FaultContract et FaultException pour résoudre ce problème. Cela vous permettra de renvoyer des messages d'erreur significatifs au client, mais uniquement lorsqu'une condition d'erreur se produit.

Malheureusement, je suis actuellement en formation, je ne peux donc pas écrire une réponse complète, mais la chance me le permet, j'apprends la gestion des exceptions dans les applications WCF. Je posterai ce soir avec plus d'informations. (Désolé, la réponse est faible.)