Input/Output MVC - Frage zum Verständnis

[Ron90]

Hi,

ich möchte/muss momentan etwas mit dem Entwurfsmuster des Model-View-Controller machen.
So ganz 100%ig blick ich da nicht durch.

-Der Controller kümmert sich um die eingegebenen Daten d.h. eine Eingabe bekommt erst der Controller und wandelt diese dann z.B. in das gewünsche Format um.
Wenn alles OK ist, dann schickt er die Daten an das Model weiter. Wenn z.B. was falsch ist, dann sagt er der View z.B. "lösche das Textfeld und gib deine Fehlermeldung aus" und die Daten gehen erst garnicht an das Model.
>>Controller kennt View und Model

-Das Model schickt die Daten immer direkt an die Views.
>>Model kennt Controller nicht

Möglicher Ablauf:
Eingabe von der Zeichenkette 10,50€ > weiter an Controller >
Controller wandelt z.B. den String in die Zahl 1050 um > weiter an Model >
Model rechnet mit 1050 > Ergebnis weiter an View
> Die View kümmert sich (immer?) um die Darstellung.

Die View fragt nur beim Model nach Informationen z.B. "Wie ist der Kontostand?"
>>View kennt Model
Sobald die View was ändern will, ist der Controller sowas wie ein Beamter der die Daten kontrolliert.
Er geht dann zum Model und sagt: "Da hat Jemand gerade 10.50€ eingezahlt", das Model aktualisiert den Kontostand und schickt die neuen Daten an alle Views.
An der Stelle ist mir wirklich unklar, warum der Datenaustausch von Model nach View geht und nicht von Model über Controller nach View?
Das Model muss doch nicht alle Views kennen? Er brauch Änderungen doch nur an den Controller zu schicken und der Controller schickt die Änderungen dann an alle Views (die er eh schon alle kennt).
Oder ist es darauf zurückzuführen, dass die Daten die ein Controller bekommt nicht immer von einer Quelle mit einer eigenen View kommen müssen (Eingabegerät: z.B. Fernbedienung für Heizung.).

mfg

 

[Evil-Devil]

Generell gesehen hast du das schon richtig verstanden. Allerdings kann man MVC nicht immer 1:1 nach dem Lehrbuch umsetzen. Zb. kommt es vor das View und Model in der selben Klasse abgebildet werden und man somit (MV)C hat.

Der Controller selbst sollte so wenig wie möglich von Models und Views kennen/wissen. Im Idealfall kennt er nur sein Modell und lässt über selbiges veranlassen das die Daten angezeigt werden.

Je nach Anwendung können in der Tat die Eingaben aus verschiedenen Quellen stammen. Zb. Benutzeroberfläche (Website), Automatismus (Server) und Datenbanken Dritter. Der Phantasie sind hierbei keinerlei Grenzen gesetzt.

 

[Icke2222]

Das Model muss doch nicht alle Views kennen? Er brauch Änderungen doch nur an den Controller zu schicken und der Controller schickt die Änderungen dann an alle Views (die er eh schon alle kennt).

Hier denke ich verstehst Du etwas falsch. Das Datenmodell kennt nichts außer sich selbst. Das View wiederum kennt das Datenmodell, da es genau dieses darstellen kann. Zum Beispiel könntest Du Dir vorstellen, dass eine Anwendung aus Personaldaten besteht. Das Datenmodell legt fest, wie so ein Datensatz, sagen wir mal eine Person aussieht. Die hat eine Personalnummer (ID), einen Namen und ein Gehalt (ist ebenso sinnfrei wie einfach).

Das View legt jetzt fest, wie man so einen Datensatz anzeigt. Dazu liest es einfach eine Person aus und bekommt ein Objekt (Exemplar einer Klasse), dass eben dem Modell zugeordnet wird.

Es muss hier also weder das Modell alle Elemente des Views kennen (ganz im Gegenteil), noch muss jedes Element im View das gesamte Modell kennen.

Tatsächlich ist es auch möglich (und für eine strikte Trennung sinnvoll) die Kommunikation stets über eine Zwischenschicht laufen zu lassen. Im MVC pattern ist die Festlegung was genau durch welche Schicht erledigt wird, nun ja, wenig strikt. Deshalb gibt es heute gerne Varianten wie MVP (wird zum Beispiel für GWT verwendet), die da etwas klarer rangehen.

 

[Spin]

Hallo Ron,

Ich möchte/muss momentan etwas mit dem Entwurfsmuster des Model-View-Controller machen.

aufgehts.

Also ein Model ist ein Domainobjekt, welches die Anwendungsdaten kapselt.
Für die Anfrage an die Datenbank sollte man sich ein Mapper bauen, der die DB Queries ausführt und anschließend das Ergebnis einem Model zu weist.

Als Anfänger musst du nur wissen, das ein Model zum speichern und laden von Daten vorgesehen ist + das halten von Daten. Sobald du dich damit mehr beschäftigst, trenne die Anfragen zur Datenbank vom Model in einen Mapper. Die Connection sollte dann in eine Factory oder in ein Singleton gepackt werden. (Vergiss den Satz - da hier zwei weitere Design Pattern angesprochen werden)

Der Controller ist der Einstieg. Controller für Detkop oder Webanwendungen ? Im beiden fällen stellt er die Steuerung der Daten dar. Der Controller kennt seine Models und seine Views und kann die Daten entsprechend weiter geben. Das ist die einfachste und legitimste Variante.

Eine andere ist das der Controller kein Model kennt und nur die Views.
Benutzeraktionen im View werden dem Controller weitergereicht, dieser wertet die Anfrage aus und aktualisiert den Zustand des Models. Das Model benachrichtigt darauf hin das View, was sich anschließend die Daten vom Model abholt und sich selbst erneuert. (Das passiert über ein Observer Pattern .. auch zu viel für den Einstieg).

Such bische im Netz, nach how to mvc in java und du findest Bieispiele ohne Ende. Du kannst dann schauen welche Kompositionen wo verwendet werden.

grüße spin

 

[Camino]

Eine andere ist das der Controller kein Model kennt und nur die Views.
Benutzeraktionen im View werden dem Controller weitergereicht, dieser wertet die Anfrage aus und aktualisiert den Zustand des Models.

Ist das nicht ein Widerspruch?! Wie soll der Controller das Model aktualisieren, wenn er es nicht kennt?

 

[Spin]

Hey Camino,

über einen ServiceLocator, vie Dependency Injection So bauen wir immer MVC Anwendungen. Unser Controller kennt keine Models, sondern nur einen EntityManager oder einen ServiceManager, die via Dependency die Abhängigen Objekte übergeben.

Aber - ich habe mich tätsächlich vertan. Der Controller darf auch bei der zweiten Variante das Model kennen, sorry.

Ich finde es aber perönlich besser, einen Controller nur die HTTP Requests oder Ereignisse entgegen nehmen zu lassen und dann zu prüfen. Die Weiterleitung dieser Ergbnisse wird dann von den Oben genannten Manager durchgegeben. Ob das nun zum ("Model" gehört oder nicht alls ich euch entscheiden - die Diskussion hatte ich schon vor .... !

Wollte das nur klar stellen@ TO das Camino auf jeden Fall richtig liegt, dass ich dort einen Widerspruch eingabut habe