Model-View-Controller Architektur und Multithreading ...?

[Castell]

Hallo,

gibt es eine "Empfehlung", wohin man die Threads einer Multithreading-Applikation packen soll, wenn man sich nach der MVC Architektur richten will?

Zum Beispiel will man eine Kreuzung simulieren. Jede Ampel besteht aus Model, das die Daten verwaltet und View, das die Ampel grafisch darstellt.
Will man nun jede Ampel in einem extra thread laufen lassen, sollte man dann die threads für jede Ampel in der Application Class (der übergeordneten Form)
erstellen, die dann jeweils eine Ampel starten oder sollte man zum Beispiel im Konstruktor jeder Ampel einen Thread erstellen, sodass die threads dann quasi automatisch in den Ampeln drinnen stecken...?

Gibt es noch andere Möglichkeiten?
Sind die beiden, die ich mir vorstelle gleichwertig?

danke für alle Antworten im Voraus,
Castell

[fanderlf]

Also erstmal würd ichs auf jeden Fall so programmieren, dass die Oberfäche gar nicht weiss dass da irgendwo Threads laufen. Eigentlich macht ja der Controller das Schalten der Ampeln. Das heisst das Schalten der Ampelfarben läuft in einem Thread im Controller. Hat eine Ampelfarbe gewechselt wird diese Zustandsänderung an den View mitgeteilt. Der View weiss aber gar nicht mehr dass die Zustandsänderung aus einem Thread kommt. Die Oberfläche zeigt nur irgendwelche Informationen mit Hilfe eines Interface an.

[gfoidl]

Hallo,

grundsätzlich hat fanderlf recht. Auf ein kleines Detail muss aber aufgepasst werden:

dass die Oberfäche gar nicht weiss dass da irgendwo Threads laufen.

Das stimmt zwar auch, aber da UI-Elemente (also die Oberfläche) nur vom UI-Thread zugreifbar sind muss dieser Zugriff per Control.Invoke vom Arbeits-Thread in den UI-Thread delegiert werden.
Da hier jedoch ein spezieller Fall vorliegt könnte im Controller auch ein SynchronizationContext verwendet werden und dort mit Post/Send der Context-Wechsel der Threads durchgeführt werden. In diesem Fall weiß dann die UI tatsächlich nichts von anderen Threads.

Um das nochmal kurz zu sagen: Die View soll dumm sein und nichts anderes machen als Daten anzeigen und die Benutzer-Aktionen an den Controler (das Herz) weiterzuleiten.


mfG Gü

[fanderlf]

MVC und Threads fortführung

Gab ja vorhin ein Thema nur leider wurde das wegen Crossposting geschlossen. Dann hab ich mit Günther direkt geschrieben. Natürlich wollen wir euch das Ergebnis nicht vorenthalten:
[Edit=gfoidl] Ich habs wieder geöffnet und die Diskussion angehängt. [/Edit]

Servus nochmal

Fand das Thema ganz interessant. Warum muss der View über Invoke aufgerufen werden? Controller arbeitet doch sowieso im Thread der UI, er wird ja von der UI instantiiert bzw. im selben Thread der UI falls man DI verwendet.
Kann denn nicht der Controller einen Thread starten und die Ergebnisse aus dem Berechnungsthread nehmen und diese an die Oberfläche weiterleiten?
Alternativ könnte man im View natürlich auch die ganzen Setter mit this.Invoke(new Action(() => txtName.Text = value; )) aufrufen.
Aber gibts nicht einfach trotzdem eine Möglichkeit einen doofen View zu haben? Im Endeffekt muss sich doch der Controller drum kümmern.

[gfoidl]

Hallo Florian,

Warum muss der View über Invoke aufgerufen werden?

Kommt darauf an wie die async. Operation ausgeführt.

Kann denn nicht der Controller einen Thread starten und die Ergebnisse aus dem Berechnungsthread nehmen und diese an die Oberfläche weiterleiten?

Dann müsste der Control aber auf den Thread warten und somit eine async. Ausführung sinnlos. Wartet er nicht liegt das Ergebnis auch im anderen Thread vor => Delegation in UI-Thread notwendig.

Alternativ könnte man im View natürlich auch die ganzen Setter mit this.Invoke(new Action(() => txtName.Text = value; )) aufrufen.

Wäre möglich. Wenn aber viele Eigenschaften geändert werden wäre es besser den Threadwechsel in einem Batch durchzuführen. So in der Art mit einer Methode DoCheadGuiAccess(...).
BTW: Invoke wird sychron ausgeführt, d.h. es wird sofort ein Threadwechsel erzwungen. Besser wäre es BeginInvoke zu verwenden denn dabei werden die Delegaten im UI-Thread scheduled -> impliziten Batching.

Aber gibts nicht einfach trotzdem eine Möglichkeit einen doofen View zu haben? Im Endeffekt muss sich doch der Controller drum kümmern.

Für diesen speziellen Fall Controler-View gibts den SynchronisationContext oder in .net 4.0 den UITaskscheduler (oder wie der genau heißt).
Generell muss sich aber die View um ihre speziellen Anforderungen kümmern. Diese spezielle Anforderung ist dass nur der UI-Thread darauf zugreifen kann. MVC sehe ich hierzu als Ausnahme von dieser Regel an. Dazu hatte ich auch mal ein Missverständnis das hier nachzulesen ist.


mfG Gü

[gfoidl]

Hallo,

da noch viele andere Crossposts existieren schließe ich das wieder
Wenn jemand (außer dem Themenstarter) eine wichtige Ergänzung hat kann er mir ja eine PN schreiben.


mfG Gü