MVC Pattern - Model aufsplitten?

[derRaab]

Hallo Leute,

ich wollte mal ganz allgemein fragen, ob es bei großen Datenmengen Sinn macht, dass Model in einzelne Teilbereiche zu zerteilen.

Ist das üblich?

[bokel]

Absolut. Ein Model besteht (meist) aus vielen Untermodellen.

[derRaab]

Danke Bokel, dachte ich mir.

Also erstelle ich EIN dickes Model in dem Instanzen von einzelnen, spezifischeren Modeln initialisiert werden (Aggregation).

Aber Listening auf Change-Events ermögliche ich nicht auf die einzelnen sondern das EINE dicke Model, oder?

M

[Omega Psi]

Wieso nicht gleich die spezifischen Modells über einen Wrapper oder Mediator adressieren?

[derRaab]

Naja, so ganz schlau bin ich leider noch nicht geworden.

Zuerst mal noch eine Frage zum MVC ansich: Es ist doch so, dass ich jegliches serverseitiges Datenupdate innerhalb des Models mache. Also ungefähr so:

* Methodenaufruf Model.addItem();
* Serverkommunikation
* Erfolgsmeldung vom Server
* Model erst jetzt aktualisieren mit neuem Item
* onChange event auslösen

Oder? Klar, dass ich die Serverkommunikation über eine zentrale Klasse manage...

Und vielleicht direkt zur Anwendung bei mir in der Software: Es gibt ein umfangreiches Datenmodell, in dem folgendes hinterlegt ist:

* Meine Presentationen
* Öffentliche Presentationen
* Meine Slides
* Öffentliche Slides
* Templates für Slides
* Meine Elemente
* Öffentliche Elemente
* Aktuelle ausgewählte Zeitleiste

Zusätzlich wird dann auch noch die aktuelle Auswahl gespeichert usw.

Ändere ich dann z. B. "selectedPresentation" durch irgend einen Controller, dann müsste ich doch folgendes tun:

* Aktuell ausgewählte Zeitleistendefinition laden
* Wenn die geladen ist ein onChange Event auslösen
* Die "Timeline" View reagiert auf das Event, ließt "selectedPresentation" aus und stellt diese dar...

Oder?

[Omega Psi]

Zitat von derRaab

Naja, so ganz schlau bin ich leider noch nicht geworden.

Zuerst mal noch eine Frage zum MVC ansich: Es ist doch so, dass ich jegliches serverseitiges Datenupdate innerhalb des Models mache. Also ungefähr so:

* Methodenaufruf Model.addItem();
* Serverkommunikation
* Erfolgsmeldung vom Server
* Model erst jetzt aktualisieren mit neuem Item
* onChange event auslösen

Oder? Klar, dass ich die Serverkommunikation über eine zentrale Klasse manage...

Ähm, also... so pauschla kann ich da nicht zustimmen oder widersprechen.

• Wieso willst du bei jeder Änderung des Datenbestandes die Änderung persistent speichern?
• Die Änderung findet schon explizit Client-seitig statt, denn dort werden die Items hinzugefügt.
• Eine Datenbank ist in erster Linie nur eine Möglichkeit, Datenbestände persitent zu speichern. Die Datenbank als Teil des Modells zu sehen, ist in meinem Augen falsch, da man so bei vielen Client-seitigen Datenmanipulationen auch jedes Mal eine Datenbanktransaktion aufbaut.

Zitat von derRaab

Und vielleicht direkt zur Anwendung bei mir in der Software: Es gibt ein umfangreiches Datenmodell, in dem folgendes hinterlegt ist:

* Meine Presentationen
* Öffentliche Presentationen
* Meine Slides
* Öffentliche Slides
* Templates für Slides
* Meine Elemente
* Öffentliche Elemente
* Aktuelle ausgewählte Zeitleiste

Zusätzlich wird dann auch noch die aktuelle Auswahl gespeichert usw.

Ändere ich dann z. B. "selectedPresentation" durch irgend einen Controller, dann müsste ich doch folgendes tun:

* Aktuell ausgewählte Zeitleistendefinition laden
* Wenn die geladen ist ein onChange Event auslösen
* Die "Timeline" View reagiert auf das Event, ließt "selectedPresentation" aus und stellt diese dar...

Oder?

Das klingt so kompliziert... sind das alles Klassen?

[derRaab]

Ich muß jede Änderung serverseitig speichern... Da geht es um eine Entwicklungsumgebung für Präsentationen. Aber vielleicht war das ein etwas blödes Beispiel. Stell Dir vor ich bearbeite ein Layout und speichere dann dieses ab. Erst auf dem Server und dann im Model. Und wenn das geschafft ist, onChange-Event (auch wenn dann die Layout ansicht nicht updated, weil es ja schon den aktuellsten Stand darstellt...)

Und im Model sind das momentan noch nicht alles Klassen. Wobei ich schon gerne für jede Liste gerne eine eigene Klasse aufsetzen möchte, in der ich dann wiederum mit typisierten Inhalten (weitere Klassen, z. B. "Slide") arbeiten kann...

M

[Omega Psi]

Also arbeitest du quasi mit einer serverseitigen Entwicklungsumgebung. Ok, das macht einiges klarer. Ich würde die Daten halt regelmässig speichern und mir die wiederholen, wenn du sie brauchst. Alles andere ist Unsinn.

Achte bei den Klassen darauf, dass du sie sinnvoll strukturierst. Einmal den Datenbestand im speicher halten und dann immer auf die jeweiligen Klassen mappen.

[derRaab]

Jo. Ich wollte ja nur noch mal sicher stellen, dass alle Serverupdates durch das Model verwaltet werden und nicht woanders...

Danke für das Feedback.

[Omega Psi]

Ja, das ist der Fall.