Funktionalitaet im Controller - Ausnahme beim Datenbezug?

[ushuaia]

hi

da ich eine groessere Applikation am planen bin, informier ich mich wieder einmal ueber geeignete designs etc... Meiner Ansicht nach ist klar, dass alle Aenderungen am Datenmodell (welche normalerweise vom GUI initiiert werden) ueber ein Controller am Datenmodell vorgenommen werden. Somit sind die Daten schoen vom GUI getrennt und die Funktionalitaet gekappselt. Die Daten wuerde ich dann noch ueber Facades vom Controller trennen, damit der Controller (Geschaeftslogik) von meiner Datenschicht (programm-interne Abbildung der Datenbank) getrennt ist. Soweit OK?
Meine naechste Frage:
ist es "OK" Controller auf Datenbereiche aufzuteilen? Damit meine ich dass pro Datenbereich (z.b. fuer alle Kundenrelevanten GUIs, fuer alle Projektrelevanten GUIs etc..) einen Controller erstelle? oder doch eher ein Controller pro GUI, oder ein Controller pro Entitaet?

Meine zweite Frage ergab sich beim durchstoebern von anderen Threads:
Wird der Datenbezug (read/view fuer Listen, Detailansichten etc.) im GUI ueber ein Controller oder direkt uebers Model gemacht? Im anderen Thread wurde geaussert dass bei Java interenen Umsetzungen wohl eher der direkte Datenbezug implementiert wurde... Meiner Meinung nach waere der Bezug ueber ein Controller wesentlich schoener, da die Kapselung nicht durchbrochen wird und die ganze Datenkonsistenz uebersichtlicher und einfacher zu unterhalten ist. Wie sind dabei Eure Vorgehensweisen?

herzlichen Dank fuer die Aufmerksamkeit
g

 

[EOB]

hi, also ich denke, wenn du swing nimmst, hast du, was controller gibt ja mit actions eine ganz nette sache verfügbar. ich weiss ja nicht, ob du vor hattest, eigene controller klassen zu implementieren?

grüße

 

[SnooP]

Während man bei Swing ja für die Darstellung von Daten in der View gut und gerne die Swing-Modelle wie z.B. TableModel verwenden kann, kann man im Webbereich hierfür entsprechende View-Beans (oder ActionForms bei Struts) verwenden, um das nochmal zu kapseln.

Also: ja... besser kapseln, aber durch die Verwendung von Swing-Modellen bekommt man das automatisch... - sprich man haut z.B. nu mal keine Modell-Entitäten direkt per add in einen JTree

Was Controller-Aufteilung angeht... es macht durchaus Sinn für versch. Aufgaben einer GUI auch einen Controller zu machen... z.B. halt für jedes Fenster einen Controller... auch wenn da relativ wenig drinsteht.

 

[Guest]

ich würde pro view einen controller nehmen
und ich würde im view einen verweis auf das model halten, damit sich die view die daten vom model hohlen kann.

zb laden von daten: user klickt, view > controller (user hat laden geklickt), view -> model (daten laden), model->view (über observer, dass daten geladen) und nun? soll beim informieren, durch das model die daten mitgesendet werden? ich finde nicht, ich mach es immer so dass nun in diesem fall, sich die view, die geladenen daten vom model hohlen soll.

 

[ushuaia]

@EOB: das heisst du implementierst die gesamte Logik in den Swing Actions? benuetze Actions eigentlich nur als Commands welche auf die eigentliche Aktion, die in einem Controller implementiert ist, verweist.

@SnooP: implementierst du denn fuer die verschiedenen GUI Modells (TableModel, TreeModel, etc.) jeweils eine extra Klasse oder implementiert deine Modelklasse (z.B. Kunden) die jeweiligen Interfaces? Ist ja eigentlich wenig vorteilhaft, da verschiedene Ansichten ein anderes SwingModell brauchen...?!

@Gast: Wieso meldet sich die View ebenfalls beim Controller wenn sie sowieso einen Verweis auf das Model hat und somit einen direkten Datenbezug macht? Beim Observerprinzip wuerde ich sagen muss der Observer die Daten vom Observable beziehen, also auf die freundliche Art...

auf jeden fall vielen Dank fuer Eure Antworten!

 

[EOB]

nö, mach ich nicht, aber ich ntze die actions als controller. von da aus ruf ich dann meine sachen auf....und öffne fenster etc.

grüße

 

[SnooP]

Eigene Klassen für jede Komponente... sprich wenn ich irgendwo nen JTree brauche, dann implementiere ich ein TreeModel als eigene Klasse - gerne aber als private bzw. auch mal als anonyme Klasse im Controller selbst. Wenn ich das gleiche Modell an mehreren Ecken wiederverwenden kann, dann halt als "richtige" eigene Klasse (kann man ja gut refactorn).
Eine Modellklasse (Domäne) darf ansonsten von sich aus keinen Bezug zu irgendwas außerhalb ihrer eigenen Schicht haben. Ein Swing-Model hat imho zu viel Abhängigkeit zur View und eignet sich daher nicht für die Domäne (das alles kann man gerne lockerer sehen, wenn man eh nur 5 Klassen baut *g*).

Für Datenaktualisierungen bieten sich by the way entsprechende PropertyChange-Events an... wenn man das Swing-Modell verändert, dann sind View-Aktualisierungen hingegen ja automatisch gelaufen...