Kennt die View das Model?

Hallo,

eigentlich heißt es ja immer, dass die View im MVC-Pattern losgelöst vom Model ist, damit man später diese einfach schnell ersetzn kann.

Doch ist es ja so, dass die View auf Events hört, die vom Model ausgelöst werden. Dazu muss es aber eine Model-Instanz haben, um ein Event anzumelden. Ist das legitim?

Th69

Nach dem klassischen MVC kennt die View das Model (beispielsweise durch Injizierung durch den Controller). Dagegen das MVP-Pattern abstrahiert soweit, daß nur der Presenter die beiden anderen Objekte kennt (und diese damit indirekt miteinander kommunizieren).

Es gibt jedoch in der Praxis eine Menge von verschiedenen MVC- und MVP-Ansätzen, so daß man je nach Projekt selber entscheiden sollte, welche Variante man benutzt (Aufwand der Abstrahierung <-> Austauschbarkeit der Komponenten).

Alles klar. Dann habe ich bis jetzt richtig gearbeitet.

Kümmert sich ein Controller stets um einen View und um ein Model oder kann er auch mehrere verwalten?

Ich hätte dazu einige Fragen:

mvc_friends schrieb:

Doch ist es ja so, dass die View auf Events hört, die vom Model ausgelöst werden.

Meiner Meinung nach: View und Model reagieren mittelbar aufeinander, der Controller vermittelt.

mvc_friends schrieb:

Dazu muss es [Anm. die View] aber eine Model-Instanz haben, um ein Event anzumelden.

Weshalb? Meiner Meinung nach sollte weder das Model, die View, noch der Controller abhängig voneinander sein. View muss vom Controller nichts wissen, wenn man ein Target Action pattern verwendet. Model könnte ein Notification pattern verwenden, um mit einem (dem Model unbekannten) Controller zu kommunizieren. (Apple's Cocoa API verwendet solch ein Muster stellenweise.)

Weshalb sollte man View und Model verbinden? Meiner Meinung nach gehen dann alle erhofften Vorteile verloren. Und wozu benötigt man dann noch einen Controller?

(Im Übrigen war der obrige Benutzername ein Tippfehler, wollte den Benutzernamen nicht mit "ass" beginnen. Mea culpa.)

Mechanics

Das ist alles sehr schwammig definiert. Ich würde auch gar nicht versuchen, mich strikt an irgendwelche Regeln zu halten.
z.B. in Qt kennt die View das Model. Einen Controller gibts in dem Konzept nicht so richtig. Nur ist es so, dass ich z.B. die Qt Modelle als Controller betrachte. Zwar auch keine "richtigen" Controller, aber auch keine richtigen Modelle. Find ich auch ok, wie das umgesetzt ist. Hier ist es einfach ein generischer Mechanismus, wie eine View Komponente auf Daten zugreifen kann. Eine View wie QListView bekommt ein "Model", und sie weiß, wie sie von dem Model Daten bekommt und welche Events sie vom Model erwarten kann. Hier braucht man keinen Controller dazwischen, der auf ein "ItemAdded" Event vom Modell horcht, und dann dem View ein neues Element hinzufügt. Das macht die View selber. Trotzdem ist es alles austauschbar, weil die View kennt nicht ein konkretes Model, sondern kann mit jedem beliebigen Model umgehen, dass diese Schnittstelle implementiert.

So wie ich das Ausgangspost lese, soll ein konkretes Modell mit der View gecoupled werden. (Der TE spricht das Problem ja im ersten Satz an.)

Die Qt Umsetzung hört sich praktisch an. Aber es ist nicht alles austauschbar, denn die "Qt-View" ist nicht austauschbar. Eine "Qt-View" kann mit jedem Model, das will, zusammenarbeiten. Das Model kann mit keinem Controller und somit auch mit keiner anderen View zusammenarbeiten, ausser diese handhabt das ähnlich der "Qt-View". Ist aber wohl nicht sehr praxisrelevant.

Mechanics

Ich wollte jetzt nicht unbedingt darauf hinaus, dass ich das System in Qt so toll finde (obwohl ich mit Qt arbeite und es durchaus ganz gut finde), sondern darauf, dass es hier verschiedene Interpretationen und Umsetzungen gibt.

Das View/Model System in Qt ist natürlich auf einander abgestimmt. Aber eine andere "View" kannst schon nehmen. Ich mein, es gibt ja schon verschiedene Views, z.B. QListView, QTreeView, QTableView usw. Und eigene Views oder Controller, die mit dem Model reden, kann man sich durchaus vorstellen. Die Schnittstelle ist ja definiert, also kann jeder problemlos auf die Daten zugreifen und auf Events reagieren.

"Qt-View" habe ich als Überbegriff für alle Views verwendet, die Qt mitbringt. "andere Views" dementsprechend Qt-fremde-Views. Ich kenne übrigens Qt nicht, verlasse mich also auf deine Ausführungen.

Verwendet man Qt, verwendet man ein Model und eine View (die Controller-ähnliche Funktion mitbringt.) Du hast Recht, man kann einen eigenen Controller und eine eigene View entwickeln. Macht man das nicht, dann hat man im Vergleich zu einem "echten" MVC pattern Zeit gespart.
Aber: meiner Meinung nach ist das kein MVC pattern, weil bei diesem alles austauschbar sein sollte. Das Qt Modell spart Zeit, wenn man keine Qt-fremden-Views benötigt. Ein "echtes" MVC pattern sollte Zeit sparen, wenn beispielsweise die View ausgetauscht werden muss. In dem von mir oben beschriebenen Design, muss nur die View entwickelt werden. Und weil bei dem Qt-Beispiel die View nicht ohne Entwicklung eines Controllers (zugunsten einer Qt-fremden-View) ausgetauscht werden kann, ist es meiner Meinung nach kein MVC design pattern. (Sondern eine praxistaugliche Abkürzung.)

Naja, was heisst schon "beliebig" austauschen? Auch eine neu entwickelte View muss sich an das Verhalten von Model bzw Controller halten.

Man kann bei Qt übrigens auch problemlos die View austauschen und das Model behalten. Das Model liefert der View die Daten in einer abstrahierten Form (Qt bietet dad as Konzept des "ModelIndex", was den eigentlich Zugriff auf die Daten abstrakt kapselt), da kann man beliebige Views schreiben.
Allerdings ist das Model-View-Konzept von Qt primär auf strukturierte Daten ausgelegt (Listen, Tabellen, Bäume). Also ein eingeschränkter Anwendungsfall, in diesem dafür mächtig und gleichzeitig sehr flexibel.

Beliebig austauschen bedeutet, dass keine Änderungen an einem Subsystem vorgenommen werden müssen, wenn man ein anderes Subsystem bloß ersetzt.

Ein noch halbwegs realitätsnahes Beispiel: ein CLI-Programm soll mittels GUI bedienbar sein. Sind Model, View und Controller voneinander getrennt, muss man nur das Model implementieren.
Mein Hintergedanke: Wie würde ein "klassisches" C Programm aussehen, das Interaktion sowohl per shell als auch per GUI bereitstellt? Wie sieht selbes Programm in einer Programmiersprache aus, die einen MVC verwenden lässt, ohne dabei Steine in den Weg zu legen?

asdfgh schrieb:

Sind Model, View und Controller voneinander getrennt, muss man nur ~~das~~ ~~Model~~ die View implementieren.