Moderatorin
Tweet
Hallo,
es geht in diesem Fall um eine Clientanwendung. Ich habe eine Viewklasse, also ein spezialisiertes Widget, das eine Detailansicht eines Datensatzes darstellt und mit dem man diesen Datensatz ändern kann. Diese Viewklasse heißt CallerDetailPane und soll für verschiedene Datensätze immer wieder benutzt werden. Dazu gibt es eine setCaller-Methode, die eine Instanz von Caller übergibt und CallerDetailPane zeigt diesen an und über Eingabefelder lässt sich dieser Caller bearbeiten.
Jetzt hätte ich 2 Möglichkeiten:
1. Die CallerDetailPane reagiert auf die Events der enthaltenen Eingabefelder und ruft direkt die entsprechenden Setter-Methoden des ihr momentan anvertrauten Caller-Objekts auf.
2. Die CallerDetailPane feuert beim Ändern von Daten eigene Events, die vom Controller abonniert werden, der dann seinerseits die Speicherung initiiert.
Beide Szenarien erscheinen mir nicht richtig. Der erste schon gar nicht, weil das View in diesem Fall direkt das Model manipuliert, aber auch im zweiten Fall hat das View zumindest lesenden Zugriff auf das Model.
Wenn der Controller die einzige Verbindung zwischen den beiden sein darf, müsste dieser beim auswählen eines anderen Callers jedes der Eingabefelder der CallerDetailPane mit den neuen Daten füllen und die CallerDetailPane müsste für jedes Eingabefeld einen Event bereitstellen, der dem Controller den neuen Wert liefert, damit der das speichert.
Dieser Weg ist zwar in meinen Augen MVC-konform, erscheint mir aber nicht atomar genug, um nicht mit Problemen rechnen zu müssen, insbesondere, wenn beim Wechsel des Caller-Objekts noch ein Event für den alten Caller feuert.
Beim GtkTreeView wird z. B. das Model auch direkt mittels set_model übergeben, was also eigentlich auch nicht MVC-like ist.
Die Frage:
Soll ich dem View lieber das Model zum Anzeigen übergeben (atomare Variante) oder alle Felder des Views einzeln mit allen Model-Eigenschaften füllen und verwaiste Events riskieren?
Danke im Voraus für eure Meinungen,
Anja
es geht in diesem Fall um eine Clientanwendung. Ich habe eine Viewklasse, also ein spezialisiertes Widget, das eine Detailansicht eines Datensatzes darstellt und mit dem man diesen Datensatz ändern kann. Diese Viewklasse heißt CallerDetailPane und soll für verschiedene Datensätze immer wieder benutzt werden. Dazu gibt es eine setCaller-Methode, die eine Instanz von Caller übergibt und CallerDetailPane zeigt diesen an und über Eingabefelder lässt sich dieser Caller bearbeiten.
Jetzt hätte ich 2 Möglichkeiten:
1. Die CallerDetailPane reagiert auf die Events der enthaltenen Eingabefelder und ruft direkt die entsprechenden Setter-Methoden des ihr momentan anvertrauten Caller-Objekts auf.
2. Die CallerDetailPane feuert beim Ändern von Daten eigene Events, die vom Controller abonniert werden, der dann seinerseits die Speicherung initiiert.
Beide Szenarien erscheinen mir nicht richtig. Der erste schon gar nicht, weil das View in diesem Fall direkt das Model manipuliert, aber auch im zweiten Fall hat das View zumindest lesenden Zugriff auf das Model.
Wenn der Controller die einzige Verbindung zwischen den beiden sein darf, müsste dieser beim auswählen eines anderen Callers jedes der Eingabefelder der CallerDetailPane mit den neuen Daten füllen und die CallerDetailPane müsste für jedes Eingabefeld einen Event bereitstellen, der dem Controller den neuen Wert liefert, damit der das speichert.
Dieser Weg ist zwar in meinen Augen MVC-konform, erscheint mir aber nicht atomar genug, um nicht mit Problemen rechnen zu müssen, insbesondere, wenn beim Wechsel des Caller-Objekts noch ein Event für den alten Caller feuert.
Beim GtkTreeView wird z. B. das Model auch direkt mittels set_model übergeben, was also eigentlich auch nicht MVC-like ist.
Die Frage:
Soll ich dem View lieber das Model zum Anzeigen übergeben (atomare Variante) oder alle Felder des Views einzeln mit allen Model-Eigenschaften füllen und verwaiste Events riskieren?
Danke im Voraus für eure Meinungen,
Anja
Kommentar