Frage zu MVC Pattern

[Guest]

Hi, Fragen zu MVC:

1) Der Controller triggert ja die View..
übergibt der Controller dabei selbst die Daten als Parameter, oder sagt er nur der view:
"es gibt aktuelle daten, hole sie dir aus dem modell" ?


2) Das Modell representiert ja meine Daten, wird dort ebenfalls eine gewisse Logik eingebaut?
zB. enthält mein Modell Klimadaten, würde ich dann eine Umrechnung in Fahrenheit in das Modell bauen?
wie sieht ein modell konkret aus?

Danke,
Gruß!

 

[maki]

Je nach anwendungszweck unterscheiden sich die MVC Architekturen.

MVC in struts ist was anderes als MVC in JSF was wiederum ganz was anderes wie in Swing ist

Solltest deine Frage schon konkretisieren.

 

[SnooP]

zu 1) beides ist möglich, z.B. kann man Events als Mechanismus nehmen, und via propertyChange Mechanismus die View aktualisieren indem die neuen darzustellenden Daten übergeben werden, oder aber man zieht die Daten direkt aus dem Modell über den Controller natürlich.

zu 2) Umrechnung gehört nicht ins Modell. Das ist eine Darstellung eines Datums, im Modell sollte man sich auf eine "Währung" einigen, alles andere wird von äußeren Formatierern verändert, das eigentliche Datum im Modell bleibt dabei ja immer gleich.

ein Modell sieht konkret meist so aus, dass es primär die Daten hält. Wenn man gut ist und objektorientiert arbeitet, dann kann das Modell die Domäne komplett abbilden, z.B. so dass es auch entsprechende business-methoden enthält. Wenn man also z.B. eine Klasse Auto hat, dann kann diese Klasse neben den tatsächlichen Daten (Modellname, Alter, Kilometerstand, maxGeschwindigkeit) auch konkrete Action-Methoden, wie "startTheEngines()" oder ähnliches haben, wenn es der Domäne gleichkommt. Häufig verkommen Domänenmodelle heute zu sog. "blutarmen" Modellen, in denen nur noch die Daten gespeichert werden, während die eigentliche Arbeit durch Services (Facades) erledigt wird... das widerspricht aber doch sehr stark der OOP, auch wenn es hip ist alles in Services auszulagern ... man sollte die Services eher als Zugangspunkt für die Domäne sehen und nicht daran gehen und die gesamte Logik nur in dieser "Zwischenschicht" zu implementieren.

 

[Gast]

Danke für die Erklärung!
Da ich mich mittlerweile mit Java Enterprise beschäftige, ich mir dieser Trend auch sofort aufgefallen mit den Services.. und das diese zum Teil nicht mehr viel mit OOP zu tun haben..

Man sieht aber an Spring dass der Trend zu den guten alten Objekten da ist

 

[byte]

Naja, Services haben schon mit OOP zu tun. Nur sollte man eben nicht die ganze Logik in die Fassade knallen sondern dort lieber auf die zuständigen dahinterliegenden Objekte delegieren.

 

[SnooP]

jo das ist richtig ... genau so sollte man es machen, so wird es aber häufig halt nicht gemacht ... und wenn man für alles ständig auf services ausweicht, hat man von dem oop dahinter auch nichts, quasi wenn die Kommunikation einzelner Modellteile nur über die Fassade passieren darf...

 

[maki]

Man sieht aber an Spring dass der Trend zu den guten alten Objekten da ist icon_smile.gif

Bei EJB 3 auch, und wenn man es richtig anstellt dann geht das auch bei EJB 2.1, POJOs anstatt Entity Beans.