Asset Management in MVC-Rahmen

[simmerl]

Wie geht ihr mit dem Thema Asset Management in Applikationen um, die mittels MVC-Pattern implementiert sind?

Der Standardfall sieht ja vermutlich meist ganz ähnlich aus:

1. Standard-Material vor dem Starten der Applikation laden
2. An einer beliebigen Stelle der Applikation auf (ggf. bereits geladenes) Material zugreifen
3. Material nachladen
4. Springe zu 2.

Wie geht ihr mit geladenen Daten um? Die View stellt geladenes Bildmaterial dar, aber wer stellt ihr dieses zur Verfügung und wann? Arbeitet ihr mit einem File-Proxy? „Singleton“ oder mit mehreren Objekten? Wie geht ihr unter Verwendung von Robotlegs mit diesem Thema um?

[Sebastian S.]

Die Schritte, die du beschrieben hast, sehen bei mir ähnlich aus.. wie vermutlich bei allen anderen auch

Bilder lade ich über ein ImageModel -> so stelle ich sicher, dass jedes Bild nur einmal geladen wird und ich direkt darauf zugreifen kann, wenn ich es benötige.. quasi immer alles cachen was geht, um die Serverrequests so gering wie möglich zu halten.

Außnahmen dazu gibts nur, wenn die Anwendung sehr viele Bilddaten läd und das den Browserspeicher volllaufen lassen könnte.

Das Model ist nicht explizit als Singleton implementiert, wird aber bei mir über Parsley injected - ist somit quasi ein Singleton, weil immer die selbe Instanz genommen wird.

[sebastian]

Bei mir kommen die Bilder in der Regel auch aus einem Model/Proxy. Hat den
auch noch den Vorteil, dass es viel besser in den Gesamtprozess zu integrieren ist.

Andererseits bietet es sich manchmal an, die Bilder einfach im View zu laden,
weil sie ohnehin nur an dieser Stelle benutzt werden und ein komplexeres Gerüst
außenrum nur mehr Arbeit mit sich bringt.

Die Wahl des Frameworks ist letztendlich Geschmackssache. Die üblichen
Kandidaten beruhen ohnehin alle auf fast den selben Prinzipien.

[simmerl]

Wie aber greift ihr auf die geladenen Daten zu bzw. wie stellt ihr sie der View zur Verfügung? Klar ist: Die Daten selbst sind gut im Model aufgehoben, die Logik hat in der View nichts zu suchen. Aber wie bringt ihr die Daten in die View (insbesondere, wenn zur Laufzeit Daten geladen werden, also nicht beim Start der Applikation)?

[sebastian]

Die Details hängen dann vom jeweiligen Framework und den genauen
Anforderungen ab. Aber vom Prinzip läuft es so ab, dass die Views über
Events/Notifications (oder wie auch immer die Benachrichtigungen im
jeweiligen Framework heißen) benachrichtigt werden, sobald sie verfügbar
sind und diese dann anschließend verarbeitet werden.

Letztendlich gehört zu einer anständigen Seitenstruktur noch viel mehr als
ein MVC Framework, das gibt echt nur den Rahmen vor. Die Ausgestaltung
hängt dann auch immer von den Anforderungen ab.

[simmerl]

Letztendlich gehört zu einer anständigen Seitenstruktur noch viel mehr als ein MVC Framework, das gibt echt nur den Rahmen vor. Die Ausgestaltung hängt dann auch immer von den Anforderungen ab.

Um die Frage, wie man innerhalb der Frameworks sinnvolle Strukturen schafft, genau darum geht es mir. Da es sich in diesem Fall ja um ein ständig wiederkehrendes Problem handelt, gehe ich davon aus, es gibt einige Vorschläge für Lösungen, auch einzelfallunabhängig

Gehen wir einmal davon aus, die Logik gestaltet sich etwa wie folgt:

1. View: Knopf wird gedrückt
2. Controller: Weist Model an, Bild zu laden
3. Model: Bild wird geladen und sendet Nachricht an das System
4. Controller: Empfängt die Nachricht ...

An der Stelle (4.) stellt sich für mich die Frage: Fügt der Controller die geladene Grafik in die View ein? Was ist mit Elementen wie bspw. einer Buffering-Anzeige:

Eine geladene Grafik (ein Kreis) wird als Kennzeichnung eines Ladevorgangs angezeigt. Es gibt also bspw. eine View-Komponente „BufferingViewComponent“ (Sprite). Dieser muss natürlich die geladene Grafik „buffering.png“ (Bitmap) in die Display-Liste eingefügt werden.

Wenn ich nun bspw. in einer View eine Buffering-Anzeige benötige, würde ich spontan folgendes schreiben (können) wollen:

var buffering:BufferingViewComponent = new BufferingViewComponent();
addChild(buffering);

Jetzt allerdings kennt dieses neue Objekt der Klasse „BufferingViewComponent“ ja noch keine Grafik „buffering.png“. Die Nachricht über die geladene „buffering.png“ ist natürlich längst verblasst ... Woher erhält (bei euch) die „BufferingViewComponent“ nun ihre „buffering.png“?

[sebastian]

Zu 4: Die Views (oder Mediatoren im Falle von Robotlegs) können sich auch
direkt bei den Models anmelden und direkt auf Änderungen reagieren.

So Dinge wie die Buffering oder Loading Grafik würde ich direkt am Anfang
laden, weil du damit ja die anschließenden Ladevorgänge visualisieren willst.
Vom Model kommen dann beispielsweise auch Notifications für Start und
Ende des Ladevorgangs, die du dann in der View (Robotlegs: Mediator)
verarbeitest