Präsentations-Set mit MVC Design Pattern und Observer

[Mendragol]

Hallo zusammen

Ich möchte eine Präsentation mit dem MVC Design Pattern und Observer realisieren und bin zur Zeit an der Planung. Dabei gibt es x-Textelemente die jeweils eine fadeIn und fadeOut Zeit besitzen. Diese Information müsste ja eigentlich das Model speichern. Nun finde ich es jedoch etwas unklar, da fadeIn und fadeOut bereits ein Teil der View widerspiegeln. Sollten diese Daten also vielleicht eher in der View liegen? Zudem, wenn diese Daten im Model liegen, wie wird die View dann informiert? Das Model müsste dann ja eigentlich prüfen ob ein Objekt zum aktuellen Zeitpunkt einer Action unterliegt und diese Information per push oder pull Methode zur Verfügung stellen. Wenn die Daten aber in der View liegen, dann kann ich nicht während der Laufzeit eine neue View generieren, da das Model nicht alle für die Präsentation nötige Daten enthält.

Für mich ist die Trennung hier noch etwas zu schwammig. Kennt sich jemand mit MVC aus und kann mir verraten wie er das trennen würde?

Danke und Gruss
Mendragol

[rendner[i]]

Dabei gibt es x-Textelemente die jeweils eine fadeIn und fadeOut Zeit besitzen. Diese Information müsste ja eigentlich das Model speichern.

Das Model enthält nur den Text in Strings gespeichert, es braucht kein Textfeld weil es ja nix anzeigen muss.
Der View hat Textfelder die den Inhalt der Strings aus dem Model anzeigen, somit ist der View für die Textfelder verantwortlich.

[Mendragol]

Da hast du Recht. Da habe ich mich wohl etwas falsch ausgedrückt. Mit fadeIn und fadeOut waren Parameter gemeint die zum String gehören. Diese kennzeichnen Start- und Endzeit. Wirklich ein Textelement wird daraus erst in der View, richtig. Ich fand es nur etwas verwirrend, aber das lag an der Bezeichnung. Ich habe jetzt einfach Start und End daraus gemacht. Wenn eine View diese Informationen halt nicht benötigt, soll sie diese halt weglassen.

Ich habe mir das nun so überlegt, dass ich im Update Object einen Parameter isAction hinzufüge und die Update Methoden, falls nötig, eine Methode des Models aufrufen die ihnen alle anzuzeigenden Textdaten (String, fadeIn, fadeOut, ...) übergibt und die View setzt diese dann um. Eine andere Möglichkeit wäre gewesen, alle Textdaten direkt bei der Initialisierung der Applikation vom Model an die View zu schicken. Aber damit könnte man ja keine dynamischen Views mehr während der Applikation erstellen. Ausser diese würden beim Anmelden beim Model die Daten erhalten.

[MaticPel]

Ausführlicher Beitrag zu MVC
Wieder einmal... ...MVC!

View
Repräsentation des Models. Erhält den Zustand und die Daten die er benötigt vom Model

Controller
Nimmt die Eingabe des Benutzers an und stellt fest, was sie für das Modell bedeutet. Er trennt die Steuerungslogik vom View und entkoppelt den View vom Model. Der Controller implementiert Verhalten für den View, aber nie Anwendungslogik. Er ist der kluge Kopf, der die Aktionen vom View in Aktionen auf dm Model übersetzt. Das Model nimmt diese Aktionen an und implementiert die Anwendungslogik, die entscheidet, welche Reaktion auf diese Aktion angebracht ist. Der Controller muss vielleicht ein bisschen arbeiten, um zu entscheiden, welche Methodenaufrufe auf dem Model erforderlich sind, aber das kann man nicht als Anwendungslogik betrachten. Die Antwendungslogik ist der Code, der die Daten verwaltet und manipuliert und dieser kommt im Model vor.

Model
Enthält die gesamte Daten-, Zustands- und Anwendungslogik.
Es kann Benachrichtigungen an den Beobachter senden.

-> verschoben