WCF - Fehler / Exceptions im Vergleich zu Nachrichten

Question

Wir haben derzeit eine Debatte, ob es besser ist, Fehler über einen WCF-Kanal zu werfen, im Vergleich zu einem Message-Passing den Status oder die Antwort von einem Dienst anzeigt.

Störungen werden mit dem integrierten Unterstützung von WCF, wo Sie die eingebauten Fehlerbehandlungsroutinen verwenden können und entsprechend reagieren. Dies ist jedoch trägt Overhead als Ausnahmen in .NET werfen kann ziemlich teuer sein.

Nachrichten können die notwendigen Informationen enthalten, um zu bestimmen, was ohne den Overhead mit Ihrem Service-Aufruf passierte eine Ausnahme zu werfen. Es ist jedoch mehrere Zeilen repetitiven Code benötigt die Nachricht zu analysieren und bestimmen Aktionen seinen Inhalt folgen.

Wir haben einen Stich an eine allgemeine Nachrichtenobjekt schaffen wir in unserer Dienste nutzen können, und das ist, was wir kamen mit:

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

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

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

Wenn alle meine Service-Anrufe diese Artikel zurückgeben, ich kann die „Erfolg“ Eigenschaft konsequent überprüfen, um festzustellen, ob alles gut gegangen ist. Ich habe dann im Fall eine Fehlermeldung Zeichenfolge etwas anzeigt schief gelaufen ist, und ein generisches Element ein Dto enthalten, falls erforderlich.

Die Ausnahmeinformationen müssen weg zu einem zentralen Protokollierungsdienst angemeldet sein und nicht aus dem Dienst übergab zurück.

Die Gedanken? Bemerkungen? Ideen? Vorschläge?

Einige weitere Klärung auf meine Frage

Ein Problem, das ich mit Fehler Verträgen habe kommuniziert Geschäftsregeln.

Wie, wenn jemand anmeldet, und ihr Konto gesperrt ist, wie kommuniziere ich das? Ihre Login offensichtlich versagt, aber es funktioniert nicht aus dem Grunde „Konto gesperrt“.

So tue ich:

A) einen boolean verwenden, werfen Fehler mit Meldung Konto gesperrt

B) zurückkehren AuthenticatedDTO mit relevanten Informationen

Answer 1

  

Dies ist jedoch trägt Overhead als Ausnahmen in .NET werfen kann ziemlich teuer sein.

Sie sind Serialisierung und De-Serialisierung Objekte zu XML und sie über ein langsames Netzwerk zu senden .. der Overhead von Auslösen einer Ausnahme ist vernachlässigbar im Vergleich zu.

Ich bleibe in der Regel zu werfen Ausnahmen, da sie etwas schief gelaufen ist und klar kommunizieren alle webservice Toolkits haben eine gute Möglichkeit, sie zu verarbeiten.

In Ihrer Probe würde ich eine UnauthorizedAccessException mit der Meldung „Konto gesperrt“ werfen.

Klarstellung: .NET WCF-Dienste Ausnahmen von FaultContracts standardmäßig übersetzen, aber Sie können dieses Verhalten ändern. MSDN: Festlegen und Handhabung von Fehlern in Verträgen und Dienstleistungen

Answer 2

Wenn Sie denken über den Dienst aufrufen wie jede andere Methode aufruft, kann es die Dinge in die richtige Perspektive helfen. Stellen Sie sich vor, wenn jede Methode, die Sie einen Status genannt zurückgegeben, und Sie es an Ihnen zu überprüfen, ob es richtig oder falsch war. Es wäre ziemlich langweilig bekommen.

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

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

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

Dies ist eine der Stärken eines strukturierten Fehlerbehandlung System, ist, dass Sie Ihre eigentliche Logik von Ihrer Fehlerbehandlung trennen können. Sie müssen nicht Kontrolle halten, wissen Sie, es war ein Erfolg, wenn keine Ausnahme ausgelöst wurde.

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

Zur gleichen Zeit, durch ein Ergebnis der Rückkehr Sie setzen mehr Verantwortung auf dem Client. Sie können auch wissen, auf Fehler im Ergebnisobjekt zu überprüfen, aber John Doe kommt herein und beginnt nur anrufen weg blind für Sie da, dass etwas nicht in Ordnung ist, weil eine Ausnahme nicht ausgelöst. Dies ist eine weitere große Stärke der Ausnahme ist, dass sie uns einen guten Schlag ins Gesicht, wenn etwas nicht in Ordnung ist und muss gepflegt werden.

Answer 3

Ich würde ernsthaft die FaultContract und FaultException Objekte mit, dies zu umgehen. Auf diese Weise können Sie Nachrichten sinnvolle Fehler an den Client zurückzugeben, aber nur dann, wenn ein Fehlerzustand auftritt.

Leider bin ich in einem Training im Moment, so kann eine vollständige Antwort nicht schreiben, aber wie es der Zufall wollte ich lerne über die Exception-Management in WCF-Anwendungen. Ich werde heute Abend mit mehr Informationen Post zurück. (Leider ist es eine schwache Antwort)