Dispatcher/Proxy (Client) Erweiterungen für besseren Durchsatz des WCF-Dienstes

Question

Benötigen Sie eine Expertenmeinung zu dieser Fallstudie.

Problemstellung/Szenario: Mein WCF-Client/Proxy benötigt ständig einige Sperrdaten vom relevanten WCF-Dienst. Genauer gesagt, ich habe einen WCF-Dienst, der Standortdaten (Stadt/Land usw.) aus einer Datenbank bereitstellt (obwohl Daten im Service zwischengespeichert werden). Einige, wie ich Serialisierung/DeSerialisierung vermeiden möchte (Objekt enthält eine Menge von verbundenen Eigenschaften sowie innere Objekte) Kosten und Service Operation Ausführung für besseren Durchsatz.

Wenige Tage zurück habe ich WCF Verhaltensweisen/WCF-Erweiterungsmethoden untersucht. Ich habe einen interessanten Artikel auf MSDN (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx) gefunden. Nachdem ich diesen Artikel gelesen hatte, dachte ich, dies könnte mir helfen, die Leistung meines Dienstes zu verbessern. Bevor ich dies umsetze, möchte ich bestätigen, dass entweder ich in die richtige Richtung denke oder eine andere Lösung mein Problem lösen kann.

Ich denke, zu implementieren, Dispatcher-Erweiterungen, um dieses Problem anstelle von Proxy (Client) Erweiterungen zu lösen. Ich habe folgende Fragen?

I) Wo (Proxy/Service Level) muss ich Erweiterungen implementieren? II) Bei der Implementierung von Dispatcher-Erweiterungen wird mein Anruf nicht an den tatsächlichen Dienst gesendet und ich spare Serialisierungs-/DeSerialisierungskosten. Richtig falsch? III) Implementieren von Dispatcher-Erweiterungen in meinem Fall ist auch besser, denn warum müssen Sie sich nicht darum kümmern, welche Proxy-Schnittstelle-Methodeaufruf aufgetreten ist, wie Caching-Logik auf der Dienstseite ist. Richtig falsch?

Bitte schlagen Sie mir eine bessere Lösung, wie ich Serialisierung/DeSerialization Kosten sparen möchte, sowie ich Datencache implementieren möchte.

Vielen Dank im Voraus /Rizwan

Answer 1

Es gibt zwei Möglichkeiten, wie ich WCF-Caching in der Vergangenheit aufgenommen haben:

1. Castle Dynamic Mit Proxies für meine Servicecontract Schnittstellen zu generieren. Diese dynamischen Proxys verwenden Interceptors, um Zwischenspeichern durchzuführen. Wenn sich die Daten nicht im Cache befinden, erstellt der Interceptor einen echten WCF-Client (ChannelFactory<TInterface>), ruft die WCF-Operation auf und speichert das Ergebnis zwischen. Ich mag diesen Ansatz, weil die Caching-Implementierung nicht wirklich WCF-spezifisch ist.

2. Implementieren Sie einen IRealProxy für WCF, der die eigentlichen Remoteoperationen umschließt und bei Bedarf Caching/Retrieval durchführt. Im Prinzip ähnelt dies Ansatz 1, aber die Implementierung ist spezifisch für WCF (mit Überresten von .NET Remoting). Ich habe diesen Ansatz vor der Migration zu # 1 verwendet. Ich migrierte zu Ansatz 1, weil Ansatz 1 Caching sowohl auf dem Client als auch auf dem Server in einer implementierungsunabhängigen Weise durchführen konnte. Zu der Zeit, rollte ich meine eigene Realproxy, aber es sieht aus wie jemand anderes da das gleiche getan hat und veröffentlicht den Code: http://blog.ngommans.ca/index.php?/archives/31-Custom-Proxy-Generation-using-RealProxy.html