Laden...

1:n Beziehung, Ereignisweiterleitung? Timer + Queue

Erstellt von Bunnychecker vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.699 Views
B
Bunnychecker Themenstarter:in
224 Beiträge seit 2009
vor 12 Jahren
1:n Beziehung, Ereignisweiterleitung? Timer + Queue

Hi,

habe ein OO Aufgabenstellung und muss diese realisieren.

Und zwar habe ich eine Klasse Manager und eine Klasse Worker.
Jedes Objekt Manager soll mindestens ein Workerobjekt implementieren (1:n Beziehung).

Mein Workerobjekt enthält 2 verschiedene Queues und jeweils für die Queue einen Timer, der beim Ablauf des Intervalls ein Objekt aus seiner jeweiligen Queue holt. Das Intervall des Timers ist flexibel, nicht nur beim Einrichten, sondern auch beim Herausholen des nächsten Objekts aus der Queue (das AutoResetEvent ist demnach auf false). Das Intervall soll vom Manager festgelegt werden und zwar so, dass sobald irgendein Timer abgelaufen ist, im Manager eine Anfrage gestartet werden muss und daraufhin das neue Intervall festgelegt wann denn das nächste Objekt in der Queue bearbeitet werden darf.
Ist das soweit logisch? Falls nicht, bitte nachfragen 😃

Nun was unklar ist:
Bekommt nun meine Workerklasse ein eigenes Event, dass ausgelöst wird, wenn irgendein Timer abläuft. Das somit eine Ereignisweiterleitung darstellt. Oder abboniere ich das TimerElapsedEreignis bereits in der Managerklasse und reagiere auch in dieser Klasse darauf?

Es kann nun sein, dass ein Managerobjekt, 10 Workerobjekte hat und diese jeweils 2 Timerobjekte und im Manager (glaube ich zumindest bisher) muss die Abarbeitung sequentiell ablaufen. Ich bräuchte demnach in meiner Managerklasse in der Ereignisbehandlungsroutine das Workerobjekt und den Timer, welcher von den beiden nun ausgelöst wurde.

Wird das Workerobjekt zum Sender und der Timer als Eventargs übergeben oder ist das so, laut Konventionen, nicht vorgesehen?

Vielen Dank schon mal für eure Antworten.

MfG

D
63 Beiträge seit 2011
vor 12 Jahren

das klingt für mich nach einem fall für ein observer pattern nicht?

also du gehst hin und sagst dem Timer

"hey timer wenn du fertig bist sag dem Manager bescheid damit der weiß das du fertig bist und ne neue aufgabe brauchst"

bildlich gesprochen.

L
667 Beiträge seit 2004
vor 12 Jahren

Da gibt es sicher nicht "die" Patentlösung. Ich denke die Realisierung ist letztendlich Geschmackssache. Aus Sicht der OO würde ich aber nicht im Manager-Objekt die Events der Timer abonnieren, sondern vom Workerobjekt heraus ein eigenes Event definieren. Damit sind die Timer dann in der Worker-Klasse gekapselt und wenn Du irgendwann entscheidest, dass statt einem Timer etwas anderes verwendet werden soll, kannst Du das in der Workerklasse intern austuaschen, ohne dein Managerobjekt zusätzlich ändern zu müssen.

Zur Frage der Weiterleitung über die Eventargs, warum willst Du den Timer als Eventargs weitergeben ? Gib doch gleich die Queue als Eventargs mit, auf die sich der Timer bezieht, dann kannst Du gleich im Managerobjekt mit der Queue arbeiten und brauchst nicht noch einen weiteren Zugriff auf das Workerobjekt.

"It is not wise to be wise" - Sun Tzu

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Bunnychecker,

Ist das soweit logisch?

für mich nicht. Versuch das ganze mal ohne Timer, Events und so zu erklären. Also nicht auf Ebene der Umsetzung, sondern auf Ebene des Konzepts. Warum sollen die Worker überhaupt warten und nicht einfach sofort die Aufträge abarbeiten, die sie bekommen? Was genau muss sequentiell passieren und was genau nebenläufig?

Zur Event-Weiterleitung (falls du die überhaupt brauchst, was ich noch nicht sehe) gibt es nur eine wirklich korrekte Lösung: siehe Event über mehrere Klassen weiterleiten.

herbivore

B
Bunnychecker Themenstarter:in
224 Beiträge seit 2009
vor 12 Jahren

Versuch das ganze mal ohne Timer, Events und so zu erklären. Also nicht auf Ebene der Umsetzung, sondern auf Ebene des Konzepts.

Ich habe das Ganze noch einmal überdacht und mir ist nun das perfekte äquivalente, einfache Beispiel eingefallen.

Es handelt sich bei meinem Konzept um ein Arbeitgeber - Arbeitnehmer Konzept.
Meine Manangerklasse ist der Arbeitgeber und meine Workerklasse ist der Arbeitnehmer.

Nun hat jeder Arbeitnehmer eine Queue, also eine Auftragswarteschlange, die er zu bearbeiten hat. (Dass das 2 Queues bei mir sind und 2 Timer, lasse ich jetzt der Einfachheit halber außen vor.).

Desweiteren brauch jeder Arbeitnehmer eine bestimmte Zeit, bis er die Aufträge abgearbeitet hat. Die Zeit, die er dafür braucht, bestimmt aber nicht der Arbeitnehmer, sondern der Arbeitgeber und der Arbeitnehmer wird auch genau zu diesem Zeitpunkt fertig, nicht eher, nicht später.

Warum sollen die Worker überhaupt warten und nicht einfach sofort die Aufträge abarbeiten, die sie bekommen?

Der Arbeitnehmer ist fertig mit seinem Auftrag, geht zum Arbeitgeber und dieser merkt, dass die nötigen Unterlagen noch nicht da sind, um den Auftrag zu bearbeiten. Daraufhin erteilt der Arbeitgeber dem Arbeitnehmer eine Pause und soll sich wider melden, wenn die Zeit abgelaufen ist.

Was genau muss sequentiell passieren und was genau nebenläufig?

Die Arbeitnehmer arbeiten alle für sich, wenn sie aber einen Auftrag abgeschlossen haben oder von der Pause zurückkommen, dann müssen sie zum Arbeitgeber um die neue Bearbeitungszeit des Auftrages zu bekommen und dazu müssen sich die Arbeitnehmer beim Arbeitgeber "anstellen".

So sollte es passen 😃

LG

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Bunnychecker,

mir ist das mit der Wartezeit oder der Pause noch nicht klar. Um das umzusetzen, was du hier schreibst, ...

Der Arbeitnehmer ist fertig mit seinem Auftrag, geht zum Arbeitgeber und dieser merkt, dass die nötigen Unterlagen noch nicht da sind, um den Auftrag zu bearbeiten.

braucht mal keine Pause im Arbeitnehmer zu realisieren, eigentlich noch nicht mal im Arbeitgeber. Der Arbeitnehmer meldet sich einfach, sobald er mit einem Auftrag fertig ist. Und der Arbeitgeber stellt den nächsten Auftrag erst ein, wenn der die nötigen Unterlagen hat. Geht also alles ganz ohne Timer.

der Arbeitnehmer wird auch genau zu diesem Zeitpunkt fertig, nicht eher, nicht später.

Wenn der Arbeitnehmer sich wirklich erst nach einer bestimmten Zeit zurückmelden soll, würde das natürlich auch gehen, vorausgesetzt, er bekommt die gewünschte Bearbeitungsdauer (zusammen mit dem Auftrag) genannt. Dann merkt er sich einfach, wann er angefangen hat, arbeitet dann einfach so schnell wie er kann, schaut am Ende auf die Uhr wieviel Zeit er noch übrig hat und legt sich solange schlafen (Thread.Sleep; einen Timer braucht man auch hier nicht).

Als Queue kannst du einfach SyncQueue <T> - Eine praktische Job-Queue verwenden.

herbivore

B
Bunnychecker Themenstarter:in
224 Beiträge seit 2009
vor 12 Jahren

Jetzt bin ich mir nicht mehr sicher, was ich genau verwenden sollte 😕

Wichtige Informationen wären noch, dass mein Arbeitnehmer die Aufträge nicht selbst bearbeiten kann, sondern diese immer mit dem Arbeitnehmer gemacht werden müssen.

Also ich hatte mir das mal so gedacht:

Mein Benutzer legt einen Auftrag an. Der Benutzer kann optional entscheiden, von welchem Arbeitnehmer der Auftrag abgearbeitet werden soll.

Der Arbeitgeber nimmt diesen Auftrag entgegen. Evtl. kann er diesen Auftrag mit dem Arbeitnehmer sofort bearbeiten (wenn die Queue leer), ansonsten legt der Arbeitgeber den Auftrag beim Arbeitnehmer in die Queue und stellt den Timer so ein, dass dieser sich erst zurückmeldet, wenn laut Berechnungen, die Unterlagen da sind.

Nun ist die Zeit abgelaufen, der Arbeitnehmer meldet sich beim Arbeitgeber zurück, Arbeitgeber schaut nach, ob die Unterlagen da sind und bearbeitet mit dem Arbeitnehmer den Auftrag. Sind die Unterlagen nicht da, wird der Arbeitnehmer (seinen Timer) mitgeteilt, wann er sich nach neuen Berechnungen zurückzumelden hat.

Kommt es zu einer gemeinschaftlichen Bearbeitung, ist die Bearbeitung immer schnell abgeschlossen und dem Arbeitnehmer wird durch den Timer wieder mitgeteilt, wann er sich wieder zu melden hat. (Er macht dann also nichts)

Mir hat sich beim Schreiben gerade die Frage gestellt, wozu habe ich noch die Queues im Arbeitnehmer?
Vielleicht sollte ich einfach alle Queues der Arbeitnehmer bereits im Arbeitgeber implementieren?

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Bunnychecker,

Jetzt bin ich mir nicht mehr sicher, was ich genau verwenden sollte 😕

geht mir genauso.

Kommt es zu einer gemeinschaftlichen Bearbeitung, ist die Bearbeitung immer schnell abgeschlossen

Das scheint mir doch der entscheidende Punkt zu sein. Alles andere sind nur Wartezeiten. Warum soll der Arbeitnehmer warten und sich dann wieder beim Arbeitgeber melden, wenn dann doch der Arbeitgeber entscheidet, ob die Arbeit beginnen kann. Im Grunde ist es doch der Arbeitgeber der die Wartezeiten vorgibt, nach Ablauf der Wartezeit prüft, ob die Arbeit beginnen kann und auch nach der Arbeit dem Arbeitgeber sagt, wie lange er wieder warten soll. Für all das braucht er den Arbeitnehmer nicht.

Der Arbeitnehmer wird im Grunde erst und nur dann benötigt wird, wenn die Arbeit tatsächlich ausgeführt werden kann. Dann benutze die Arbeitnehmer auch nur dann und nur dafür. Dafür reicht die genannte Queue, in die der Auftrag erst dann eingestellt wird, wenn er auch tatsächlich zu diesem Zeitpunkt erledigt werden kann. Der Arbeitnehmer arbeitet also immer erst, wenn der Arbeitgeber sagt, jetzt geht es los. Er arbeitet dann immer so schnell er kann. Er wartet nie, außer eben auf neue Aufträge, die er dann wieder sofort ausführt.

Alles andere kann und sollte der Arbeitgeber selber machen.

herbivore