Entscheidung: ein Dienst mehrere Verträge oder viele Dienste

Question

Ich verwende .NET 4, um eine kleine Client-Server-Anwendung für einen Kunden zu erstellen. Sollte ich einen riesigen Dienst erstellen, der viele Verträge (IInvoice, IPurchase, ISalesOrder usw.) implementiert, oder sollte ich viele Dienste erstellen, die jeweils einen Vertrag auf vielen Ports ausführen? Meine Fragen sind speziell an den Vor- und Nachteilen beider Wahlmöglichkeiten interessiert. Wie lautet die übliche Art, diese Frage zu beantworten?

Meine wahre Dilemma ist, dass ich keine Erfahrung dieser Entscheidung haben, und ich habe wenig genug Erfahrung mit wcf, dass ich helfen, die technischen Auswirkungen einer solchen Entscheidung zu verstehen müssen.

Answer 1

Erstellen Sie keinen großen Service, der eine Anzahl von Serviceverträgen implementiert. Diese Arten von Diensten sind leicht zu erstellen, werden aber zu einem Maintenance-Kopfschmerz und werden sich nicht gut skalieren lassen. Außerdem erhalten Sie alle Arten von Code-Zusammenführungskonflikten, wenn eine Entwicklergruppe um Check-Ins/Check-Outs konkurriert.

Erstellen Sie auch nicht zu viele Dienste. Vermeiden Sie die Falle, Ihre Dienste zu feinkörnig zu machen. Versuchen Sie, Dienste basierend auf einer Funktionalität zu erstellen. Die Methoden, die von diesen Diensten verfügbar gemacht werden, sollten auch nicht feinkörnig sein. Sie haben besser weniger Methoden, die mehr tun. Vermeiden Sie das Erstellen ähnlicher Funktionen wie GetUserByID (int ID), GetUserByName (string Name), indem Sie einen GetUser (userObject user) erstellen. Sie haben weniger Code, einfachere Wartung und bessere Auffindbarkeit.

Schließlich sind Sie wahrscheinlich gehen nur einen Port egal zu müssen, was Sie tun.

Answer 2

Sein scheint, dass Sie zwischen Datacontract (n) und Servicecontract (s) mischen. Sie können einen ServiceContract und viele DataContract (s) haben, die genau Ihren Anforderungen entsprechen.

Answer 3

In Echtzeitanwendungen Sie haben einen Service-Vertrag für jede Einheit wie Rechnung, Kauf und Salesorder haben getrennten Servicecontract

jedoch für jeden Dienstleistungsvertrag wird es heterogene Clients wie Rechnung wird von Back-Office über Windows-Anwendung aufgerufen werden using netNamedPipeBinding oder netTcpBinding und gleichzeitig Client-Anwendung muss den Dienst mit basicHttpBinding oder wsHttpBindings aufrufen. Grundsätzlich müssen Sie für jeden Dienst mehrere Endpunkte erstellen.

Answer 4

Sie sollten die Entscheidung treffen, um die Last zu erwarten basierend, Erweiterbarkeit benötigt und Zukunftsperspektive. Da Sie "kleine Client-Server-Anwendung für einen Kunden" geschrieben haben, gibt es keine klare Vorstellung von der beabsichtigten Verwendung der vorliegenden Entwicklung. Mr. Big's Antwort muss auch berücksichtigt werden.

Sie sind herzlich eingeladen uns auf eine weitere Frage mit spezifischen Daten oder Angaben über die Situation in der Hand gesichert zu setzen. Vielen Dank.

Answer 5

Sie würde in der Regel verschiedene Dienste für jede Haupteinheit wie IInvoice, IPurchase, ISalesOrder erstellen.

Eine weitere Option ist das Trennen von Abfragen von Befehlen. Sie könnten einen Befehlsdienst für jede Haupteinheit haben und Geschäftsvorgänge implementieren, die nur die Daten akzeptieren, die sie für die Ausführung der Operation benötigen (vermeiden Sie CRUD-artige Operationen); und ein Abfragedienst, der die Daten in dem vom Client benötigten Format zurückgibt. Dies bedeutet, dass der Befehlsteil das zugrunde liegende Domänenmodell/die zugrunde liegende Geschäftsebene verwendet. während der Abfrageservice direkt auf der Datenbank operiert (um das Geschäft zu umgehen, das für die Abfrage nicht benötigt wird). Dies vereinfacht die Abfrage einer Menge und macht sie flexibler (geben Sie nur das zurück, was der Client benötigt).

Answer 6

Die Trennung von WCF-Diensten oder anderen Diensten ist ein Balanceakt.Das Prinzip besteht darin, dass Sie die Komplexität unter Druck halten und gleichzeitig die Leistung in Betracht ziehen wollen.

Je mehr Dienste Sie erstellen, desto mehr Konfiguration müssen Sie schreiben. Außerdem erhöhen Sie die Anzahl der Proxy-Klassen, die Sie auf der Clientseite erstellen und pflegen müssen.

Wenn Sie zu viele ServiceContracts auf einen Service setzen, erhöht sich die Zeit, die zum Generieren und Verwenden eines Proxys benötigt wird. Wenn Sie jedoch nur ein oder zwei Operationen für einen Vertrag abschließen, haben Sie dem System Komplexität hinzugefügt, die nur sehr wenig zu gewinnen ist. Dies ist kein wissenschaftliches Rezept, aber eine gute Faustregel könnte etwa 10-20 OperationContracts pro ServiceContract sagen.

Klassenkopplung ist natürlich eine Überlegung, aber beschäftigen Sie sich wirklich mit getrennten Angelegenheiten? Es hängt davon ab, was Ihr System tut, aber die meisten Systeme befassen sich nur mit ein paar Bereichen, die von Interesse sind, so dass die Aufteilung der Dinge die Klassenkopplung sowieso nicht so stark verringert.

Eine andere Sache zu erinnern, und das ist sehr wichtig ist, um Ihre Methoden so allgemein wie möglich zu machen. WCF behandelt DataContracts aus einem bestimmten Grund. DataContracts bedeutet, dass Sie jedes Objekt an den und vom Server senden können, solange die DataContracts bekannt sind.

So zum Beispiel könnten Sie 3 OperationContracts haben:

[OperationContract] 
Person GetPerson(string id); 

[OperationContract] 
Dog GetDog(string id); 

[OperationContract] 
Cat GetCat(string id); 

Aber, so lange diese alle bekannten Typen sind, können Sie diese in einem Betrieb wie verschmelzen könnte:

[OperationContract] 
IDatabaseRecord GetDatabaseRecord(string recordTypeName, string id); 

Letztlich ist dies bei der Gestaltung von Serviceverträgen das Wichtigste. Dies gilt für REST, wenn Sie eine DataContract-Serialisierungsmethode wie die Serialisierungsmethode verwenden.

Zuletzt, gehen Sie alle paar Monate über Ihre ServiceContracts zurück und löschen Sie Operationen, die nicht von den Clients verwendet werden. Dies ist ein weiterer großer!