Laden...

SOA Design, Provider hängen von anderen Providern ab

Erstellt von Tarion vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.024 Views
T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 11 Jahren
SOA Design, Provider hängen von anderen Providern ab

Ich hab schon einiges über SOA gehört und gelernt, das meiste bezieht sich auf Services. Jetzt habe ich mehrere Provider die von anderen Providern abhängen.

Beispiel:
Ein TimeProvider gibt die aktuelle Zeit
Ein PlayerStateProvider nutzt intern jede Sekunde den TimeProvider, um festzuhalten, wann sich der Zustand des Spielers geändert hat.

Aktuell hängt der PlayerStateProvider (und andere Provider) direkt vom TimeProvider ab.

Ist das nun schlechtes Design? Und warum?

Wenn ich dass in einem Service implementieren würde, müsse der Service:
Von PlayerStateProvider und TimeProvider abhängen und den PlayerStateProvider regelmäßig aktiv nach dem Zustand des Spielers fragen. Denn wird der PlayerStateProvider mal nicht gefragt, bekommt er die Zeit, wann sich der Zustand geändert hat nicht mit.

Wie designe ich das ganze am besten Serviceorientiert?

771 Beiträge seit 2009
vor 11 Jahren

Die Abhängigkeit per se ist ja dort kein Problem. Du solltest die Abhängigkeiten aber zwingend über Interfaces darstellen, so dass du dann diese Klassen separat testen kannst (z.B. per Mocking). Und wenn du dann noch per Dependency Injection (DI) die Schnittstellen übergibst, dann hast du die lose Kopplung sichergestellt.

Ein anderer Ansatz wäre die Daten per Event anzubieten und eine äußere Server-Instanz verbindet die Provider miteinander (so daß diese sich direkt nicht kennen).

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 11 Jahren

Den Äußeren Server will ich halt vermeiden, da der Provider darauf angewiesen ist, dass er regelmäßig den Zustand prüft. Dieses Wissen sollte ein Service, der den Provider nutzt nicht haben.

Die Provider hängen alle über Interfaces zusammen. Aktuell ist alles überschaubar und ich verbinde es direkt im Code ohne extra DI Container. Aber das lässt sich bei bedarf nachrüsten.

F
10.010 Beiträge seit 2004
vor 11 Jahren

Irgendwie verwechselst Du hier was.
SOA bedeutet nicht das alles als Windows/Web/WCS Service erstellt wird, sondern das Dienstleistungen als Services zur Verfügung stehen.
Ob das "einfach" eine Klasse ist oder ein echter Service ist nebensächlich.

Insofern ist das was Du als Provider bezeichnest schon ein Service.

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 11 Jahren

FZelle, nach deiner Erklärung kann ich das ganze dann so beschreiben:
Ich habe einen TimeService und einen PlayerStateProvider sowie einen PlayerStateService. Nun hängt der PlayerStateProvider vom TimeService ab.

Dann ist die Frage: Ist es sinnvoll, dass ein Provider von einem Service abhängt? Oder sollte diese Abhängigkeit von einem Service gekapselt werden?

Warum die Unterscheidung zwischen PlayerStateService und PlayerStateProvider?
Weil der PlayerStateService Konsumerorientiert und Stateless ist, im Gegensatz zum PlayerStateProvider

Ich sehe aktuell auch keine Probleme in meinem Design, ich interessiere mich nur für Konzepte und Good Practice.

F
10.010 Beiträge seit 2004
vor 11 Jahren

Das ist ja das schöne bei SOA.

DU entscheidest was Deine Klassen oder Services als Dienstleistung benötigen.
Wenn es diese Dienstleistung bereits in form eines Interfaces gibt, wird es benutzt.
Wenn nicht, wird ein Interface erstellt das diese Dienstleistung beschreibt und ggf der Service erstellt.

Solange du das per Interfaces entkoppelst ist es genau das wie SOA gedacht ist.