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.

Haben Sie versucht, WCF-tracing?
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

Schreibe einen Kommentar