WCF und Schnittstellenvererbung - Ist dies eine schreckliche Sache zu tun?

Question

Meine Anwendung hat 2 "Dienste", sagen wir, eine ist eine grundlegende (Integer) Rechner, und eine ist ein Gleitkomma-Rechner. Ich drücke diese als Schnittstellen wie folgt aus:

public interface IBasicCalculator
{
    int Add( int a, int b );
}

public interface IFloatingPointCalculator
{
    double Add( double a, double b );
}

Ich möchte diese über WCF bereitstellen. Leider WCF scheint sehr eng an die Vorstellung, dass jede mögliche Operation, die Sie aussetzen möchten, muss durch eine einzige Service-Schnittstelle gehen gebunden werden - Sie können nicht Sitzungen zwischen den Diensten teilen, es ist umständlich von der Client-Seite, wie Sie einen separaten Proxy für jeden erstellen müssen, es scheinen keine "Sub-Services", etc...

Ich bin also zu dem Schluss gekommen, dass ich eine "kombinierte" Schnittstelle (man könnte sie auch als Fassade bezeichnen) präsentieren muss, etwa so:

[ServiceContract]
public interface ICalculatorService : IBasicCalculator, IFloatingPointCalculator
{
    [OperationContract(Name = "AddInt")]
    new int Add( int a, int b );

    [OperationContract(Name = "AddDouble")]
    new double Add( double a, double b );
}

Wenn ich dies tue, dann stellt WCF beide Methoden dem Client zur Verfügung, der sie aufrufen kann, und alles funktioniert tatsächlich.

Eine solche "Vererbung der Schnittstellen" scheint jedoch unhandlich zu sein. Besonders el new int Add y new double Add . Streng genommen, new bei einer Methode bedeutet, dass eine darunter liegende Methode versteckt wird, was ich eigentlich gar nicht tue. Ich kann die new aber dann erhalte ich nur Compiler-Warnungen, die auf "Ich glaube, ich verstecke diese Methode, Sie müssen sie in Methode umbenennen oder sie mit 'new' versehen" hinauslaufen.

Dies ist also eine zweiteilige Frage:

1. Bin ich auf dem richtigen Weg mit meinem "kombinieren alles in eine Schnittstelle" Logik, oder gibt es tatsächlich eine Möglichkeit, "Sub-Dienste" oder "mehrere verknüpfte Dienste" mit WCF auszusetzen?

2. Gibt es einen besseren Weg, wenn dies notwendig ist?

Danke!

Answer 1

Ich habe gerade herausgefunden, dass man mehrere Endpunkte (die jeweils eine andere Schnittstelle verwenden) für denselben Dienst bereitstellen kann und man trotzdem nur EINE Proxy-Lib auf dem Client generieren muss, die den Zugriff auf alle ermöglicht, was mein Problem vollständig löst.

Answer 2

Ich würde sagen, im Allgemeinen nicht. Denken Sie daran, dass Sie es mit einer verteilten Anwendungstechnologie zu tun haben, nicht mit einer verteilten Objekttechnologie, so dass Konzepte wie Vererbung nicht anwendbar sind.

Im Allgemeinen würde ich diesen Weg nicht gehen, sondern eher spezifische Verträge haben, die die logische Gruppierung von Operationen darstellen, die Sie über den Endpunkt bereitstellen wollen.

Answer 3

Ich glaube allerdings, dass das, was Sie beschreiben, nicht wirklich eine bewährte Praxis ist. Sicherlich ist es möglich, mehr als einen Dienstvertrag für einen Diensttyp zu implementieren, da es sich lediglich um die Implementierung mehrerer Schnittstellen handelt.

WCF ermöglicht die Unterstützung mehrerer Endpunkte, die über eindeutige URIs und unabhängige Verträge kommunizieren. Die Tatsache, dass die Klasse ClientBase beispielsweise nur einen Vertragsschnittstellentyp akzeptiert, impliziert, dass Proxy-Klassen, selbst wenn sie in derselben Bibliothek gespeichert sind, nur eine Vertragsschnittstelle implementieren müssen.

Wenn es Ihnen tatsächlich gelingt, nur eine Proxy-Klassendefinition zu erstellen, würde ich gerne wissen, wie Sie das geschafft haben. Vielleicht verstehe ich Ihre Bedürfnisse aber auch falsch. Die Implementierung verschiedener Proxy-Klassen gibt Ihnen die ultimative Flexibilität, da die OperationContractAtrribute-Werte wie IsInitiating und IsTerminating wahrscheinlich für verschiedene Verträge unterschiedlich sein werden. Wenn Sie die Schnittstellen zweier Verträge kombinieren, wie in Ihrem Beispiel, ändert sich möglicherweise die Art und Weise, wie Sie die Methoden des Service-Vertrags attribuieren würden.