Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Warum FaultContract in WCF benutzen?
tkrasinger
myCSharp.de - Member



Dabei seit:
Beiträge: 582
Herkunft: Enzesfeld (Niederösterreich)

Themenstarter:

Warum FaultContract in WCF benutzen?

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
GarlandGreene
myCSharp.de - Member



Dabei seit:
Beiträge: 499
Herkunft: Emmerich, NRW

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
BhaaL
myCSharp.de - Member

Avatar #erP6yAFiewXrJTqrvg6R.jpg


Dabei seit:
Beiträge: 656

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 7559
Herkunft: Waidring

beantworten | zitieren | melden

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!"
private Nachricht | Beiträge des Benutzers