Laden...

Warum FaultContract in WCF benutzen?

Erstellt von tkrasinger vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.109 Views
T
tkrasinger Themenstarter:in
574 Beiträge seit 2008
vor 11 Jahren
Warum FaultContract in WCF benutzen?

Ich hab heute mal ein kurzes Testprogramm zur Verwendung von FaultContracts in der WCF gebaut und dabei festgestellt, dass es rein performance technisch besser ist, das Object der FaultException<T> nicht als Exception zu throwen sondern beim return wert (sofern eine Klasse) als Property anzuhängen.

In meinem, sehr einfachen, Testprogramm brauchen 8 Testdurchläufe mit

throw new FaultException<ValidationFault>( new ValidationFault() { ErrorCode = x, ErrorMessage = msg})

gegenüber

result.Fault = new ValidationFault() { ErrorCode = x, ErrorMessage = msg};

etwa um ein 25% mehr Zeit, da jeder, in einer FaultEx resultierender Aufruf etwa 300ms braucht, statt etwa 15ms bei der Variante über die Property.

Warum also sollte man FaultContracts benutzen?

G
497 Beiträge seit 2006
vor 11 Jahren

der FaultContract ist einfach Teil der Service-Schnittstelle. Man spezifiziert damit nicht nur das Format der Anfragen und Antworten, sondern auch das Format eventueller Ausnahmen, die im Dienst auftreten. Der Client muss diese ja auch verarbeiten können. Ein Entwickler kann aber, wenn er den Dienst nicht selber entwickelt hat, nicht vorhersehen, welche Ausnahmen er denn erwarten kann, also muss auch hier eine definierte Schnittstelle her, die zumindest den Informationsaustausch zwischen Dienst und Client standardisiert. Zudem ist der FaultContract eine gute Möglichkeit, Fehler im Dienst nicht nach aussen weiterzuleiten. Das ist auch ein potentieller Angriffspunkt.

656 Beiträge seit 2008
vor 11 Jahren

Der Zeitunterschied liegt aber btw. im werfen der Exception, wo unter anderem der Stacktrace usw. ermittelt werden - und das ist nunmal langsam, egal ob es jetzt eine InvalidOperationException oder eine FaultException<MyTypedFault> ist.

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo tkrasinger,

schau dir mal an was über die "Leitung" im Fehlerfall geschickt wird (mit Fiddler, o.ä) wenn du FaultContract<T> od. nicht verwendest. Dann wirst du auch sehen was GarlandGreene erklärt hat.

Da Exceptions eben Ausnahmen sind und nicht zur Ablaufsteuerung verwendet werden sollten, spielt es mMn keine große Rolle wenn in so einem Ausnahmefall das etwas länger dauert.
Für die Services kann in Hinblick auf die Skalierbarkeit auch eine Status zurückgegeben werden (ähnlich wie es mit den HTTP-Statuscodes der Fall ist).

Bei der Validierung ist es sowieso nicht nötig dies mittels Exception zu lösen, denn es gibt andere Wege, die du ja auch verwendest.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"