WCF service-Attribut zu melden Methodenaufrufe und exceptions
Habe ich eine Anforderung zur Anmeldung jeden Methodenaufruf in einem WCF-Dienst und alle Ausnahmen geworfen. Dies führte zu viel redundanter code, da jede Methode enthalten muss, die boilerplate ähnlich wie diese:
[OperationContract]
public ResultBase<int> Add(int x, int y)
{
var parameters = new object[] { x, y }
MyInfrastructure.LogStart("Add", parameters);
try
{
//actual method body goes here
}
catch (Exception ex)
{
MyInfrastructure.LogError("Add", parameters, ex);
return new ResultBase<int>("Oops, the request failed", ex);
}
MyInfrastructure.LogEnd("Add", parameters);
}
Gibt es eine Möglichkeit, ich kann die Kapseln alle diese Logik in ein Attribut MyServiceLoggingBehaviorAttribute
, die ich anwenden könnte, um die service-Klasse (oder Methoden) so:
[ServiceContract]
[MyServiceLoggingBehavior]
public class MyService
{
}
Hinweis #1
Erkenne ich, dass dies getan werden kann, mit Aspekt-orientierte Programmierung, aber in C# die einzige Möglichkeit, dies zu tun ist, ändern bytecode, die erfordert die Verwendung eines Drittanbieter-Produkt wie PostSharp. Ich möchte vermeiden, mit kommerziellen Bibliotheken.
Hinweis #2
Beachten Sie, dass Silverlight-Anwendungen sind der primäre Konsumenten der Dienstleistung.
Hinweis #3
WCF-Ablaufverfolgung ist eine gute Möglichkeit, in einigen Fällen, aber es funktioniert hier nicht, da, wie oben erwähnt, ich brauche, um zu überprüfen, und im Fall einer Ausnahme zu ändern, ist der Rückgabewert.
Ich bin nicht fließend in der WCF-tracing -- möglicherweise erfüllt die Anmeldung die Anforderung, in jedem Fall aber ich glaube nicht, dass es ermöglichen würde, wickeln jeden Methodenaufruf in einem try-catch und die Rückgabe einer
ResultBase<T>
Objekt nach der Ausnahme.Ja, tut mir Leid; ich hatte nicht bemerkt, dass Anforderung. Nicht sicher wie klug das ist, aber...
Ich wäre neugierig zu hören, was insbesondere sorgen Sie sich über die relative Weisheit, die sich nähern. Tatsächlich, anfangs hatte ich eine Lösung, die verging, nicht abgefangene Ausnahmen (
IncludeExceptionDetailInFaults
), und verändert die ausgehenden Nachrichten mit IDispatchMessageInspector
so dass Silverlight kann die Meldung angezeigt werden und nicht die gefürchteten "NotFound". Aber ich verschrottet, weil der einige seltsame Probleme mit dem hinzufügen der benutzerdefinierten Endpunkt Verhalten, und weil einige legacy-client-code, stützte sich auf die ResultBase
Ansatz. (Ich kann post, die Lösung hier zu, wenn ich eine minute.)Vor allem, haben Sie bemerkt, dass Sie nicht geben, Sie wurden mit Silverlight? Ich nehme an, Sie sind den Umgang mit REST-services? Ansonsten, meine erste Einwand ist, dass Sie nicht mit SOAP-Fehler. Ich würde ungern die Tatsache, dass Sie die Fragen Ihrer Anrufer zu überprüfen, return-codes, um zu bestimmen, ob oder nicht es gibt ein problem. Ausnahmen (und damit Fehler) sind wesentlich sauberer.
InformationsquelleAutor McGarnagle | 2012-12-01
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ja, es ist möglich, die Kapselung dieser Art der Protokollierung, mit der die Erweiterungspunkte eingebaut, WCF. Tatsächlich gibt es mehrere mögliche Ansätze. Die, die ich hier beschreibe, fügt ein
IServiceBehavior
, die verwendet eine benutzerdefinierteIOperationInvoker
, und erfordert keine Internet.config-änderungen.Besteht aus drei teilen.
IOperationInvoker
, die umhüllt den Methodenaufruf in der gewünschten logging und error-handling.IOperationBehavior
gilt, dass der invoker aus Schritt 1.IServiceBehavior
, die erbt vonAttribute
, und gilt das Verhalten von Schritt 2.Schritt 1 - IOperationInvoker
Den Kern der IOperationInvoker ist die
Invoke
Methode. Meine Klasse umschließt die base-invoker in einem try-catch-block:Schritt 2 - IOperationBehavior
Die Umsetzung der IOperationBehavior einfach wendet das benutzerdefinierte dispatcher für den Vorgang.
Schritt 3 - IServiceBehavior
Diese Umsetzung
IServiceBehavior
gilt die operation Verhalten an den Dienst; es sollten die Erben vonAttribute
so, dass es angewendet werden kann als ein Attribut der WCF-service-Klasse. Die Implementierung für diese ist standard.Es scheitert in Betrieb.Verhaltensweisen.Hinzufügen, wenn ich mehr als einen Endpunkte. Wahrscheinlich sollten wir Operationen Sammlung nur von 1-Endpunkt oder prüfen, ob dieses Verhalten bereits Hinzugefügt...
Unfortunly funktioniert nicht in meinem Fall. Verhalten wird nur nie aufgerufen wird...
Prüfen Sie, ob es einen anderen
ServiceBehaviours
mit dem Dienst verbunden. Das könnte der Fall sein.Funktioniert nicht für asynchrone Methoden.
InformationsquelleAutor McGarnagle
Können Sie versuchen, Audit.NET Bibliothek mit Ihren Audit.WCF Erweiterung. Es können sich die WCF-service-Interaktion und ist kompatibel mit asynchronen Aufrufe.
Alles, was Sie tun müssen, ist, schmücken Sie Ihre WCF-service-Klasse oder Methoden, die mit der
AuditBehavior
Attribut:Den WCF-Erweiterung verwendet eine
IOperationInvoker
UmsetzungInvoke
undInvokeBegin
/InvokeEnd
. Sie können den code hier.InformationsquelleAutor thepirat000