Warum trennt man beim MVC-Pattern View und Controller?
-
Das scheint mir in den meisten Fällen wenig sinnvoll, denn meist ist das doch das gleiche. Wieso sollte die View über den Controller gehen müssen, wenn dieser seinerseits wiederum nur an das Model delegiert?
Bei einem normalen Programm mit GUI hab ich Steuerelemente, die irgendwie den Zustand des Models anzeigen und noch irgendwelche Knöpfe und Menüs, um das ganze zu steuern, ist also sowohl View als auch Controller.
Ähnlich bei einem Server: eine Client-Instanz ist View und Controller gleichzeitig: sie empfängt Zustandsupdates und sendet sie an den Client, empfängt aber auch Anweisungen für das Model vom Client.
Einzig auf Client-Seite macht es vielleicht Sinn. Da die Netzwerklogik und das Serialisieren nicht unbedingt trivial ist, scheint mir da eine eigene Controller-Klasse tatsächlich sinnvoll.
Aber wieso sollte ich in den anderen Fällen die Implementierung der beiden Konzepte auseinander reißen und damit den Code unnötig aufblähen?
-
Generell gebe ich dir Recht, da es heutzutage selten Sinn macht View und Controller zu trennen (z.B. bei GUI Widgets). Hier kommt dann das MVP zum Spiel
asen schrieb:
Das scheint mir in den meisten Fällen wenig sinnvoll, denn meist ist das doch das gleiche. Wieso sollte die View über den Controller gehen müssen, wenn dieser seinerseits wiederum nur an das Model delegiert?
Das klassische MVC speichert im Model die zugrunde liegenden Daten, welche durch die Views (es kann mehrere Views geben!) abgefragt werden können. Der Benutzer interagiert nur mit den Views, welche die Interaktion wieder an den Controller weiterleiten, der dann entscheiden kann was passieren soll. Dabei können sich z.B. die Daten im Model ändern (der Controller verändert diese), was dazu führt, dass das Model die Views über die neuen Daten benachichtigen muss.
asen schrieb:
Bei einem normalen Programm mit GUI hab ich Steuerelemente, die irgendwie den Zustand des Models anzeigen und noch irgendwelche Knöpfe und Menüs, um das ganze zu steuern, ist also sowohl View als auch Controller.
Hier würde ich zwischen View und Controller unterscheiden: Eine Checkbox kann ausgegraut sein, d.h. sie kann nicht verändert werden. Um das zu gewährleisten müssen sich die verschiedenen Controller untereinander absprechen unter welchen Bedingungen die Checkbox wieder aktiviert wird. Diese Logik gehört offenbar nicht in die des Checkbox Views. (Hier wäre ein Einsatzgebiet von einem Presenter aus MVP)
asen schrieb:
Ähnlich bei einem Server: eine Client-Instanz ist View und Controller gleichzeitig: sie empfängt Zustandsupdates und sendet sie an den Client, empfängt aber auch Anweisungen für das Model vom Client.
Sehe ich nicht so. Ein Client ist kein Controller sondern View. Clienten entscheiden nicht wie die Daten verändert werden, sondern sie haben nur Wünsche (Benutzerinteraktionen), die sie an den Server weiterleiten. Der Server ist Controller und Model ohne Views.
---
Quellen:
http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference
http://aviadezra.blogspot.de/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html
-
Biolunar schrieb:
asen schrieb:
Ähnlich bei einem Server: eine Client-Instanz ist View und Controller gleichzeitig: sie empfängt Zustandsupdates und sendet sie an den Client, empfängt aber auch Anweisungen für das Model vom Client.
Sehe ich nicht so. Ein Client ist kein Controller sondern View. Clienten entscheiden nicht wie die Daten verändert werden, sondern sie haben nur Wünsche (Benutzerinteraktionen), die sie an den Server weiterleiten. Der Server ist Controller und Model ohne Views.
Ähm.
Ja, man kann es so machen. Man kann es aber auch anders machen. Viele Applikationen haben verdammt viel Logik die im Client läuft. Hat viele Nachteile, aber natürlich auch Vorteile.
Und da die Vorteile von beiden Lösungen zu kombinieren nicht gerade einfach ist, macht man oft nen Tradeoff.
Dabei kommt dann je nachdem was man für anforderungen hat ein sehr "dummer" Client raus (dumm=keine Business-Logik im Client=das was du beschrieben hast), oder eben ein nicht ganz so dummer (=doch ein wenig bis viel Business-Logik im Client).
-
Das scheint mir in den meisten Fällen wenig sinnvoll, denn meist ist das doch das gleiche. Wieso sollte die View über den Controller gehen müssen, wenn dieser seinerseits wiederum nur an das Model delegiert?
Bei einem normalen Programm mit GUI hab ich Steuerelemente, die irgendwie den Zustand des Models anzeigen und noch irgendwelche Knöpfe und Menüs, um das ganze zu steuern, ist also sowohl View als auch Controller.
Beim MVC sollst du gerade das ja nicht machen, sondern die Schichten sauber trennen, mit dem Gewinn "Jetzt kann ich die View beliebig austauschen etc"
Wenn du sagst "bei normalen Programmen hab ich das aber anders" ist das schon zu spät :p
