MVC Pattern mit GUI und Threads (best practice)

Und das man sich die View-Abhängigkeiten in den Controller einschleppt und dann die Komplexität von MVC hat ohne den Vorteil der angepeilten SoC.
@bERt0r - Hast recht, mein Diagramm oben zeigt MVC ohne Observer.

Ich hatte die Frage zwar schon mal in einem eigenen Thread gestellt, würde sie hier aber gerne doch noch mal wiederholen da es vielleicht auch ein wenig in Richtung der Frage des TO geht :

Wer kennt eigentlich wen und warum ?

Mir ist auch klar das es vom “reinen” MVC auch noch Varianten gibt wie z.B. mit zusätzlichem Observer oder in Richtung Presenter, aber leider werd ich auch aus der Graphik bei Wiki nicht wirklich schlau.

Mir ist auch klar das es vom „reinen“ MVC auch noch Varianten gibt wie z.B. mit zusätzlichem Observer oder in Richtung Presenter, aber leider werd ich auch aus der Graphik bei Wiki nicht wirklich schlau.

Das ist es ja gerade auf das sich niemand einigen kann. Es gibt kein „reines“ MVC, MVC ist auch nicht der heilige Gral der jedes Programm super macht sondern nur ein weiteres Softwarearchitekturpattern. Und wie bei jedem anderen Pattern kommt es immer darauf an, zu wissen wo und wie man es einsetzt. Diese absolut-Aussagen von schlingel a la „View-Abhängigkeiten in den Controller einschleppt“ zeugen nur davon dass er versucht aus MVC ein Allheilmittel zu machen - als Hammer der auf alle Nägel passt.

Wenn du dir z.B die Ursprünge von MVC ansiehst: https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html siehst du dass die wieder ein anderes Bild da haben, da ist die Kopplung von View und Controller noch viel expliziter dargestellt.

So ein Blödsinn. Weil MVC immer gut passt, hab ich auch was zu dem Thema MVP und MVVM gemacht. Ja, fast richtig :wink:

Wo liest du das? Z.B. aus?

Der Punkt ist, wie heute auch, dass hier - noch bevor es die Begriffe gab - versucht wurde die Applikation so zu strukturieren, dass die Komponenten dem Benutzer zugänglich sind. Diese Komponenten sollen offensichtlich über fest definierte Schnittstellen kommunizieren und sonst nicht vermengt werden - wie es View-Klassen ala Swing im Controller tun würden.

Heute sprechen wir von Seperation of Concerns und trennen die Komponenten noch schärfer um sie besser testen zu können. Warum du @bERt0r ) darauf beharrst, dass eine fehlende Norm hier gleich Beliebigkeit bedeutet leuchtet mir nicht ein. Eher glaube ich, dass du hier Kopplung via Schnittstellen mit fehlender Kohäsion verwechselst und deshalb meinst, dass Abhängigkeiten überall eingeführt werden können wie man lustig ist. Obwohl man dann gegen das Single Responsibility Prinzip verstößt und sich die Separation of Concerns nicht mal mehr aufzeichnen kann.

BTW: Trotz falscher Unterstellung ein guter Link!

[quote=Sen-Mithrarin]
Auf was @bERt0r glaube ich hinaus will ist, dass das von System zu System verschieden gelöst wird. Die gängigen MVC server seitigen Frameworks machen es mit dem Controller in der Mitte. Dieser kennt Model und Views. Bei einem Request ruft er die entsprechenden Model-Klassen auf, nimmt das Ergebnis und steckt es in die View. Die wird dann returniert.

Dann gibt’s die Varianten wo View und Model direkt gekoppelt werden. Zusätzlich kennt der Controller das Model. Bei Input ruft dann der Controller die entsprechenden Methoden im Model auf, was dann wiederum durch die Änderung den neuen Zustand der View mitteilt.

Oder du nimmst überhaupt ein MVC-Derivat. In der Praxis setzen sich immer mehr sogenannte MV*-Implementierungen durch wo es so gelöst wird wie es am besten passt.

Supplement heisst ergänzen, gemeint ist, der Controller soll nicht zur Kommunikation von Views untereinander verwendet werden (dies geht über das Model). Das drückt auch das Diagramm aus (das wieder anders als die oben aussieht :smiley: )

Da siehst du auch ganz schön wie die View und Controller eher „vermengt“ dargestellt werden, getrennt vom Model. Schnittstellen gibt es nicht zum Selbstzweck. Inwiefern ein Controller Bezug zur View nehmen kann/soll/muss hängt vom Anwendungsfall ab. Klar kann man alles auf Teufel komm raus entkoppeln, das macht aber einfach nicht immer Sinn. Zu viele Schnittstellen erhöhen die Komplexität und erhöhen dadurch die Fehleranfälligkeit.

Ich finde es irgendwie immer wieder interessant wie schwammig man es teilweise formulieren und so unendlich großen Spielraum für Eigeninterpretationen lassen kann.

Wenn ich mir schon ein Design-Pattern überlege das bestimmte Element und deren “Aufgabe im Ganzen” definiert, und eigentlich auch die Beziehung dieser Elemente zueinander, sollte ich dies auch unmissverständlich klar festlegen.
Einige lassen halt alles über den Controller laufen, andere verbinden die Module fest miteinander und wieder andere lösen es “umgedreht” mit Listenern. Letzten Endes alles MVC, und doch irgendwie keins von allem.
Und das MVC nur eines von vielen ist ist mir durch aus Bewusst und ich würde auch keines als “DAS” Pattern festlegen (ist auch auf Grund unterschiedlicher Anfroderungen gar nicht möglich).
Schon irgendwie merkwürdig : da sucht man sich ein Pattern aus, versucht sich halbwegs daran zu halten (so gut es eben bei dieser schwammingen Grundlage möglich ist) und kann am Ende doch alles machen wie man lustig ist.

Entweder hab ichs halt komplett überhaupt nicht verstanden oder ich denke zu über-kompliziert.

Ergänzung: Zum SwingWorker gibt’s im Byte-Welt-Wiki einen passenden Beitrag von André Uhres.

Na eben nicht. Der Controller schickt Nachrichten, „Messages“, an die View um Aktionen zu triggern. Der ruft nichts direkt auf. Steht im selben Dokument.

Das stimmt.

Stimmt auch. Ändert nichts daran, dass View und Controller zwar zusammen arbeiten aber zwei getrennte Komponenten sind.

Am Ende ist es wichtig, dass es in der Applikation konsistent ist und man die Trennung - für welche Trennschärfe man sich auch entscheidet - durchzieht. Den Controller, der ja im besten Fall mit einem gemockten View und gemockten Model genauso funktionieren soll, mit View-Code zu beschmutzen ist und bleibt für mich ein No-Go. Anscheinend nicht für alle.

Ich seh’ ein, dass man das macht wenn man sich bewusst dafür entschieden hat. Ich würd’s trotzdem nicht so machen.

Ich finde die MVC-Diskussion immer wieder unterhaltsam. Für die Diagramme kann man sich mal https://www.google.de/search?q=model+view+controller+diagram&tbm=isch anschauen. Je nachdem, wie überzeugt man von … irgendwas, im Zweifelsfall, von sich selbst … ist, wird man das eine oder andere als “falsch” ansehen, nicht antizipierend, dass der Abstand zwischen so einem Diagramm und dem Code stets größer ist, als der aller beliebiger Diagramme untereinander.

Ich finde die MVC-Diskussion immer wieder unterhaltsam.

:smiley: Ich auch. Ich könnte mich Stunden darüber auslassen. @schlingel : Was wenn ich dir sage, dass nach meinem „Idealbild“ von MVC der Controller gar keine Messages oder Aufrufe an die View schickt sondern lediglich die Benutzerinteraktionen entgegennimmt und an das Model leitet, welches per Observer pattern die View(s) benachrichtigt?

Dass du 'ne moderne Version verwendest als die in dem Paper von 1979. Überrascht mich aber nicht weiters :wink:

Ich persönlich spiel im Moment mit Reactive Programming und MVVM rum, falls es dich interessiert.