MVC in einer Three-Tier-Architektur: Best practices?

Moin,

ich bastle im Moment an eine eher theoretischen Frage. Gegeben sei
eine typische CRUD-Applikation, mit Datenbank-Layer, Fachkonzeptebene
und MVC-GUI-Schicht. Also zum Beispiel eine Webapplikation, die eine
Artikelliste anzeigt, und bei Bedarf weitere Informationen zu
einzelnen Artikeln.

Meine Frage bezieht sich jetzt auf das "übliche Vorgehen" bei der
Reihenfolge der Objektmaterialisierung und welche Objekte daran
typischerweise partizipieren, so dass ich a) eine möglichst
weitgehende Trennung der Verantwortlichkeiten habe, b) unnötigen
Overhead jedoch ebenfalls vermeide.

Prinzipiell sehe ich zwei Möglichkeiten: Entweder wird erst das
View-Objekt erzeugt, welches dann merkt, dass es noch gar kein
Fachkonzept zur Anzeige kennt und welches dann dafür Sorge trägt, dass
das Fachkonzept materialisiert wird. Wenn das da ist, kann man die
benötigten Daten anzeigen. Etwa so:

Die Applikation kreiert die ArtikelListeView. Diese wiederum stellt
fest, dass das Fachkonzept ArtikelListe noch nicht materialisiert
ist, und beauftragt einen Broker, dies zu erledigen. (Hier spielt
dann auch noch die Frage nach der Materialisierung der einzelnen
Objekte und ggfs. Caching mit rein, aber das ignoriere ich jetzt
mal.)

Oder aber es wird erst das Objekt auf der Ebene des Fachkonzepts
erzeugt und materialisiert und dann das zugehörige View-Objekt.

Wenn der Benutzer Details zu einem Artikel sehen will, sorgt der
ArtikelListenController dafür, dass das zugehörige Artikel-Objekt
(mittels eines eigenen Brokers) materialisiert wird, erzeugt den
ArtikelView, assoziert die beiden und dann läuft das "übliche"
MVC-Spielchen zwischen den beiden ab, d.h., sobald das View-Objekt
sich beim Modell als Observer gemeldet hat, von diesem ein Update
bekommt, um sich die anzuzeigenden Daten abzuholen.

Beide Vorgehensweise haben einiges für oder gegen sich. Für das erste
Vorgehen spricht, dass dies zumindest zum Teil eher dem Vorgehen etwa
in GUI-Frameworks zu entsprechen scheint: Die Objekte zum Anzeigen von
Komponenten bringen in der Regel ja Routinen mit, um andere
(Sub-)Komponenten anzuzeigen. Der Nachteil scheint mir zu sein, dass
mir die Logik irgendwie verdreht zu sein scheint (man hat noch nichts,
was man anzeigen könnte und muss sich das erst besorgen) und außerdem,
dass sich die GUI-Schicht mit Fragen der Datenbeschaffung befassen
muss (es sei denn, man delegiert das gesamte Brokering an das
Fachkonzept, was mir aber auch nicht wirklich plausibel erscheint [1]).
Aber immerhin würde man das Wissen auf die beteiligten Objekte
insofern beschränken, als das nur ArtikelListeView und
Artikelliste-Objekte wissen müssen, wie letztere aus der
Datenhaltung materialisiert werden.

Für das zweite Vorgehen scheint mir vor allem zu sprechen, dass man
die richtige Reihenfolge einhält. Auf der anderen Seite stellt sich
jedoch die Frage, warum sollte eigentlich etwa der
ArtikelListenController wissen müssen, wie Artikel-Objekte (nicht
ArtikelListen-Objekte!) materialisiert werden, nur damit dann ein
anderes View-Objekte erzeugt werden kann.

Mir geht es wie gesagt, um Einschätzungen, was "üblich" oder
"praktikabel" ist. Ich finde bisher eigentlich nur Einstiegsliteratur,
die MVC prinzipiell erläutert, die aber genau solche Fragen der
Objekterzeugung nicht abdeckt. Ich wäre auch für Literatur-Pointer
sehr dankbar.

Liebe Grüße

Holger


Footnotes:
[1]  Kurz zur Erläuterung: Das hieße, "leere" Objekte zuerst zu
erzeugen, die dann sobald sie nach was gefragt werden, sich erst mal
mit Leben füllen müssen. Klingt irgendwie nach Skeletten und
Gespenstern und so.

--
---          http://hillview.bugwriter.net/            ---
Fachbegriffe der Informatik - Einfach erklärt
32: Vaporware
Dampf, den man der Konkurrenz macht. (nach Peter Berlich)
[ Auf dieses Posting antworten ]
Antworten

Stefan Ram (01.03.2007 15:05)
Holger Schauer (02.03.2007 10:02)