MVC in Anwendung

[denniz]

Hi Leute,

ich möchte eine kleine Applikation auf MVC Basis umsetzten.
Ein Skizzierung der Anwendung hab ich hier mal hochgeladen. Wie ihr seht ist dort eine Uploader abgebildet sowie ein Datagrid welche die hochgeladenen Dateien anzeigen soll.
Der Dateinname wird dabei nach einem Upload in einer DB gespeichert.

Ok, jetzt hab ich einige Probleme mit der Schichtenarchitektur.

1) Das Model soll die Daten speichern welche in der Datenbank hinterlegt sind.
Soll das Model eine klasse aggregieren welche den Datenbankrequest/response regelt und die Daten dann an das Model übergibt,
oder soll ich den Request in den Controller einbauen welcher dann bei einem Response die Daten in das Model schreibt?

2) Darf die View eine Referenz auf das Model haben über die dann direkt die Daten aus dem Model ausgelesen werden könnten
oder dürfen View/Model nichts voneinder wissen? Darf der Datentransfer zwischen Model und View demnach dann nur von Controller übernommen werden?

3) Hätte ich bei dieser Anwendung nicht mehrere Views , Model & Controller? Also eine View für die Liste und eine View für den Uploader. Demnach hätte ich ja dann auch
gleich 2 Modelle und Controller oder seh ich das falsch?

4) Wo werden die listener zb für den Uploadbutton registriert, in der View oder im Controller?

Vielleicht hab ihr ja noch paar Tipps wie ich das Ding logisch aufbauen kann.

Gruß

[Omega Psi]

Zitat von denniz

Das Model soll die Daten speichern, welche in der Datenbank hinterlegt sind.
Soll das Model eine klasse aggregieren welche den Datenbankrequest/response regelt und die Daten dann an das Model übergibt,
oder soll ich den Request in den Controller einbauen welcher dann bei einem Response die Daten in das Model schreibt?

Das Model bildet den Zustand der Applikation ab. Services kennt der Controller und modifiziert so das Model.

Zitat von denniz

Darf die View eine Referenz auf das Model haben über die dann direkt die Daten aus dem Model ausgelesen werden könnten
oder dürfen View/Model nichts voneinder wissen? Darf der Datentransfer zwischen Model und View demnach dann nur von Controller übernommen werden?

Das Model kennt die View nicht. Aber der Controller darf beides kennen.

Zitat von denniz

Hätte ich bei dieser Anwendung nicht mehrere Views , Model & Controller? Also eine View für die Liste und eine View für den Uploader. Demnach hätte ich ja dann auch
gleich 2 Modelle und Controller oder seh ich das falsch?

Es gibt immer nur ein Model. Controller kannst du pro View oder auch nur einen implementieren.

Zitat von denniz

Wo werden die listener zb für den Uploadbutton registriert, in der View oder im Controller?

Hängt von der Implementierung ab. Du kannst den Listener in der View haben und dort den Controller aufrufen oder der Controller kennt die View. Dann bekommt die View einen Listener im Controller.

[denniz]

Zitat von Omega Psi

Services kennt der Controller und modifiziert so das Model.

Wäre es nicht einfacher wenn man die Services quasi als ein weiteren Proxy in das Model aggregiert?
So müßte ich ja erst die Daten zum Controller senden und von da aus wieder zum Model, oder spricht dies gegen das MVC konzept?

[JoH]

Darf die View eine Referenz auf das Model haben über die dann direkt die Daten aus dem Model ausgelesen werden könnten
oder dürfen View/Model nichts voneinder wissen? Darf der Datentransfer zwischen Model und View demnach dann nur von Controller übernommen werden?

Die View kann sich als Listener beim Model registrieren und sich so beiBedarf updaten.
Der Controller kann den View auch direkt updaten (z.B. wenn er keine Änderungen am Model vornimmt).

[Omega Psi]

Zitat von JoH

Die View kann sich als Listener beim Model registrieren und sich so beiBedarf updaten.
Der Controller kann den View auch direkt updaten (z.B. wenn er keine Änderungen am Model vornimmt).

Ersteres beschreibt Databinding in Flex. Zweites würde ich vor allen Dingen dann implementieren, wenn sich ein View zum Beispiel öffnen oder schliessen soll, den Zustand wechseln soll oder ähnliches.

Zitat von denniz

Wäre es nicht einfacher wenn man die Services quasi als ein weiteren Proxy in das Model aggregiert?
So müßte ich ja erst die Daten zum Controller senden und von da aus wieder zum Model, oder spricht dies gegen das MVC konzept?

Ja, das wäre eine einfache Möglichkeit. Die Frage die sich hierbei stellt ist allerdings: was ist das Model?

Das Model selbst ist erst einmal ein Abstraktum. Ich würde allerdings das Model in erster Linie auf das Domain Model beziehen. Das ist der Core der Applikation. Diese Klassen müssen sinnvoll miteinander assoziiert werden sonst ist die Applikation falsch konzipiert. Die bezieht aber keine Proxies, Mediatoren etc mit ein - das sind Datentypen, die du in erster Linie für die Infrastruktur möchtest. Erst an dieser Stelle spielen Services eine Rolle. Diese sind aber auch aussen vor, wenn es um das Applicationmodel geht. Modelle tragen nur den Zustand einer Applikation in sich. Die (komponentenbasierte) Infrastruktur, in der die Daten transformiert wird, wird als Architektur verstanden. Hier erst wirst du dich um die Services (Proxies, Delegates) kümmern.

Eine granulare Modellierung deiner Applikation nach diesem (grob) vorgestellten Konzept hat den Vorteil, dass du zum einen Probleme schneller und besser kommunizieren kannst. Zumal diese Aufteilung auch durchaus vernünftig ist, da du so Verantwortlichkeiten besser abbilden kannst.