MVC Muster
-
Hallo,
ich versteh nicht genau was die Präsentation und die STeuerung ist.
Also view und controller.
Die view zeichnet die Oberfläche und nimmt die Benuterinteraktionen entgegen.
Was macht der Controller ?
-
Die View ist einfach deine Grafikschnittstelle, die das ganze zeichnet. Die nimmt gar keine "Benutzerinteraktionen" entgegen, denn dafür ist der Controller da.
Der Controller steuert alle Änderungen des Modells. Z.b. drückt dein Benutzer irgendne Taste, der Controller reagiert darauf und ändert demnach das Model.
Die View und der Controller stehen i.d.R. gar nicht miteinander in Kontakt. Die View greift auch nur auf das Model zu und holt sich die Daten daraus.
-
Eigentlich nimmt die View schon Benutzereingaben entgegen. Die werden dann an den Controller weitergeleitet, welcher dann bei Bedarf für ein Update des Modells sorgt. Wenn dem nicht so wäre, dann hätte man für Benutzeringaben irgendwelches GUI-Zeugs fest verdrahtet im Controller, und das Pattern soll ja gerade solche Abhängigkeiten verhindern.
-
Wenn man mit GUIS arbeitet, ist das ganze doch eher dazu gedacht das, was man tatsächlich sieht, austauschbar macht, während die "Steuerung" gleich bleibt, oder? In dem Fall kann man doch Benutzerklicks etc. direkt vom Controller annehmen lassen, und die View zeichnet wirklich nur die Buttons, Felder etc.
Würde für mich zumindest mehr Sinn machen. Wozu hat man denn sonst ne Trennung zwischen View und Controller (wenn auf einen Austausch der GUI eh eine andere Steuerung folgen würde)
Na gut, kann sein, dass festgesetzte GUI Systeme wie Swing da sehr unflexibel sind und sich die Eingaben nicht wirklich von den grafischen Objekten trennen lassen, aber damit habe ich bis jetzt noch nicht gearbeitet, daher kann ich dazu nix sagen.
-
TravisG schrieb:
Wenn man mit GUIS arbeitet, ist das ganze doch eher dazu gedacht das, was man tatsächlich sieht, austauschbar macht, während die "Steuerung" gleich bleibt, oder? In dem Fall kann man doch Benutzerklicks etc. direkt vom Controller annehmen lassen, und die View zeichnet wirklich nur die Buttons, Felder etc.
Würde für mich zumindest mehr Sinn machen. Wozu hat man denn sonst ne Trennung zwischen View und Controller (wenn auf einen Austausch der GUI eh eine andere Steuerung folgen würde)
Na gut, kann sein, dass festgesetzte GUI Systeme wie Swing da sehr unflexibel sind und sich die Eingaben nicht wirklich von den grafischen Objekten trennen lassen, aber damit habe ich bis jetzt noch nicht gearbeitet, daher kann ich dazu nix sagen.
Ich hab da auch ein Problem mit. Der Controller kann ja oft nicht direkt die Benachrichtigungen annehmen. Z.B. soll bei 'nem Klick irgendwas noch in der GUI verschoben werden, dann muss das ja zumindest vorher über das View gehen. Oder die View muss aus dem Kontext entscheiden, welche Aktion zu tätigen ist. Oder erst validieren. Klicks usw außerhalb des Views zu behandeln passt imho nicht, wegen der starken Abhängigkeit.
Views sollten ja auch komplett unterschiedlich sein können (in der strengen Theorie), z.B. einmal GUI, einmal Kommandozeile, andermal Webinterface. Ich verstehe nicht, wo dann die Geschäftslogik hin soll. Stecke ich sie in das Model, braucht die View den Controller nicht mehr. Stecke ich sie in den Controller, ist das Model eine reine Datenbank und laut deutscher Wikipedia soll der Controller keine Daten manipulieren.
-
TravisG schrieb:
Wenn man mit GUIS arbeitet, ist das ganze doch eher dazu gedacht das, was man tatsächlich sieht, austauschbar macht, während die "Steuerung" gleich bleibt, oder? In dem Fall kann man doch Benutzerklicks etc. direkt vom Controller annehmen lassen, und die View zeichnet wirklich nur die Buttons, Felder etc.
Würde für mich zumindest mehr Sinn machen. Wozu hat man denn sonst ne Trennung zwischen View und Controller (wenn auf einen Austausch der GUI eh eine andere Steuerung folgen würde)
Ein klick im View tut aber nicht zwangsläufig das Model betreffen.
In einer Webanwendung ist es zB so, dass das view selber nicht auf eingaben reagiert, sondern das alles der Controller macht (zB postback). In anderen Situationen ist es aber so, dass das View erstmal die eingaben filtert und ansieht. zB ist ein klick auf einen Reiter nicht unbedingt eine notification an den Controller wert. Und da ist auch schon der interessante Punkt: das View notifiziert (:p) den Controller über eine Aktion. In einer Webumgebung ist es zB oft so, dass das View dazu garnichts tun muss (es setzt nur den korrekten Link) in Desktop Anwendungen oder besser gesagt Rich-Interface Anwendungen hat das View selber aber eine gewisse eigene Logik.
Der Controller interessiert sich ja nur dafür, was der User jetzt abschicken/bestätigen will. Wenn er nur Items aus Listen hin und her kopiert, Daten Drag&Dropt etc. handelt dass das View alles. Sobald ich aber Übernehmen klicke sagt das View dem Controller: Action Foo ist passiert. Je nachdem wie die Struktur ist, sendet das View die Daten mit oder der Controller holt sie sich selbst vom View.
Design Pattern sind keine fixe statische Sache - sie sind eine Vorlage auf der die Implementierung passiert. Deshalb sind so Aussagen wie View spricht nie mit Controller falsch. Denn je nach Implementierung kann es diese Kommunikation sehr wohl geben.
Die Idee von MVC ist ja lediglich, dass man Model, View und Controller trennt. Man kann sogar soweit gehen, dass man im View selber wieder ein MVC Pattern hat. Denke zB an Richt Internet Applications. Das View rendert die HTML Seite und darin haben wir mit JavaScript wieder ein MVC. Dessen Model dann zB der originale Controller ist (der dann wiederum an das originale Model weiter leitet).
PS:
meistens ist es sowieso notwendig das View mit dem Controller zu vernetzen was Eingaben betrifft, da es zB sonst unmöglich wäre das View zu tauschen. Man bedenke zB die unterschiedlichen Event Notifications in gtk und der winapi.
-
Der Controller ist also nichts anderes als eine Klasse die vom view
daten empfängt und gegenfalls das Model ändert ?
Der Controller ist als ein reiner Vermittler ?
-
Shade Of Mine schrieb:
Design Pattern sind keine fixe statische Sache - sie sind eine Vorlage auf der die Implementierung passiert. Deshalb sind so Aussagen wie View spricht nie mit Controller falsch. Denn je nach Implementierung kann es diese Kommunikation sehr wohl geben.
iedlichen Event Notifications in gtk und der winapi.Ich finde aber, dass gerade beim MVC-Pattern die Meinung sehr auseinander gehen, an welcher Stelle die Grenze zwischen den beteiligten Komponenten zu ziehen sind. Bei anderen Patterns entdecke ich relativ zügig die dahinterliegenden Ideen, beim MVC-Pattern (oder auch Model-View Presenter) bin ich eher verwirrt und das Pattern hilft mir nicht wirklich weiter...
-
blurry333 schrieb:
Der Controller ist also nichts anderes als eine Klasse die vom view
daten empfängt und gegenfalls das Model ändert ?
Der Controller ist als ein reiner Vermittler ?In vielen Fällen ja.
Ich denke das schönste, weil klarste Beispiel ist ein Webframework wie zB Rails, Symfony, etc.
Das View sind die Templates
Das Model ist die Business Logik
Der Controller ist der dispatcher der die Anfrage des Clients an das Model weiterreicht (uU gefiltert) und die Ausgabe des Models an das View weiter leitet. (Manchmal ist es auch so, dass das Model dann direkt dem View die Daten gibt).Der Controller ist aber im Prinzip ein Vermittler, ja. Denn das Model interessiert sich nicht wirklich für den User. Das Model hat nur die Business Logik drin. der Controller versucht nun diese reine Business Logik mit der reinen Präsentationslogik des Views zu verknüpfen.
Ein Taschenrechner zB hätte als Model ein System das addieren, subtrahieren, etc. kann. Das View weiss wie man Eingaben entgegen nimmt. Der Controller verarbeitet die eingaben nun so, dass das Model etwas damit anfangen kann. uU ist das nur ein simples durchreichen. In solchen Fällen spricht man dann auch teilweise von Document/View. Es kann aber auch sein, dass man die Daten nicht so einfach weitergeben kann, dann muss der Controller arbeiten und die Daten aufbereiten. zB könnte das View die Daten ja als verschlüsseltes XML per SOAP senden...