nicht angemeldet
Model View Controller - Was gehört wo hin?
Hallo Forum,
vielleicht haben andere ja schonmal ein ähnliches Problem gehabt.
Ich habe MVC bisher so verstanden:
- Controller: steuert anhand von URL-Parametern, welche Action (= Model?) aufgerufen werden soll
- Model/Action: Verarbeitet Daten, hat Verbindung zur Datenbank, bestimmt, welche View als nächstes angezeigt werden soll (forward) bzw. welche Action als nächstes (redirect)
- View: Stellt Informationen dar (HTML) bzw. steuert die Nutzereingaben (JavaScript)
Was mir nun nicht klar ist: Bestimmte Informationen, die ich aus einer Datenbank erhalte, benötige ich ausschliesslich zur Darstellung in der View. Sollte ich trotzdem immer den Umweg über die Action/das Model gehen, welches die Daten sammelt und an die View weiterreicht? Oder ist es legitim in der View selbst einen Datenbank-Connect aufzubauen? Eine Action kann ja schliesslich zu mehreren Views forwarden, da erscheint es mir nicht richtig, die View-spezifischen Daten zentral zu sammeln.
Für Anregungen bin ich dankbar!
Beste Grüsse, Peter
-
MVC stammt aus der objektorientierten Programmierung und wurde meines Wissens zuerst in Smalltalk verwendet.
Ähnliche Architekturen haben sich dann später überall verbreiten, Microsoft-Anwendungen arbeiten sehr stark nach dem Prinzip.Dieses Modell auf Browser, HTML und JS zu übertragen ist ehrlich gesagt Humbug.
Zwar kannst du da Affinitäten feststellen, aber das bringt keine Erkenntniss, da du dich ja immer nur im Teil der 'MVC' Architektur bewegst.
Bildlich: wenn du ein Zimmer einrichtest, dann interessierst du dich auch nicht unbedingt für das ganze Gebäude.Wenn du es so willst ist eine fertig ausgelieferte Website eine View, und der serverseitige Script arbeitet auf dem Document/Model.
Scripte in der View zählen auch zu der View (weil Daten und Algorithmen sowieso eins sind 'Neumann-Prinzip').-
Hallo flashnfantasy,
Dieses Modell auf Browser, HTML und JS zu übertragen ist ehrlich gesagt Humbug.
Es geht hier ja auch vor allem und die Serverseite. Außerdem kann man natürlich auch für eine Javascript Anwendung das MVC-Muster verwenden.
Scripte in der View zählen auch zu der View (weil Daten und Algorithmen sowieso eins sind 'Neumann-Prinzip').
Was soll denn hier ein Konzept für Prozessoren?
Zur ursprünglichen Frage:
Das Model ist der Teil der Anwendung, der sich um die Daten und die darauf möglichen Operation kümmert.
Wenn man eine Datenbank basierte Anwendung hat, ist die Datenbank Teil des Modells oder liegt darunter. Jedenfalls greift man nicht am Modell vorbei auf die Datenbank zu.
Das Modell sorgt auch dafür, dass die Daten konsistent sind. Die Operationen, die es unterstüzt, sind solche, die nur mit den Anwendungsdaten zu tun haben.
Also bei einem Forum beispielsweise: Neuer Thread, Neues Posting, Thread übersicht holen, Posting holen, usw.Views holen sich Daten aus dem Modell (z.B. ein Posting) und stellen sie dar.
Die Ereignisse (wie z.B. "Benutzer drückt Knopf") von den Views gehen dann an den Kontroller. Der ruft dann die Notwendigen Operationen des Modells auf und erzeugt einen neuen View.Es ist durchaus auch möglich, dass es direkte Interaktion zwischen View und Modell gibt. Ein View könnte z.B. die Möglichkeit bieten, Daten zu verändern und greift dazu direkt auf das Modell zu.
Dem Kontroller kommen dann nur noch allgemeinere Verwaltungsaufgaben zu.
Zum Beispiel die Views zu Koordinieren, zu entscheiden, welche View angezeigt wird, wenn ein anderer verlassen wird etc.
Bei Webanwendungen ist das meiner bescheidenen Erfahrung nach aber eher unüblich.Grüße
Daniel
-
Hallo Daniel,
Dieses Modell auf Browser, HTML und JS zu übertragen ist ehrlich gesagt Humbug.
das sehen ein paar wenige Entwickler aber ganz anders ;-)
Siehe Mojavi für PHP, Java Struts und viele andere Web-Frameworks, die zum Teil Quasi-Standards sind. Die Frage nach dem ob stellt sich also (IMHO) nicht.Trotzdem danke und beste Grüsse, Peter
-
-
Hallo Peter
Was mir nun nicht klar ist: Bestimmte Informationen, die ich aus einer Datenbank erhalte, benötige ich ausschliesslich zur Darstellung in der View. Sollte ich trotzdem immer den Umweg über die Action/das Model gehen, welches die Daten sammelt und an die View weiterreicht?
IMHO hängt das von den Daten ab. Wenn sie sich auf das Model oder das System, welches das Model modeliert, beziehen, dann solltest du nicht direkt darauf zugreifen. Wenn du aber zum Beispiel Layout-Informationen in der DB speicherst, die sich nur auf einen ganz bestimmten View beziehen, dann kannst du direkt auf die DB zugreifen. Noch sauberer ist es natürlich, wenn du auch dafür ein Model machst, welches du für ähnliche Views benutzen kannst.
Oder ist es legitim in der View selbst einen Datenbank-Connect aufzubauen?
Anscheinend musst du eine DB-Verbindung aufbauen, die Frage ist halt, ob du das direkt im View machen oder etwas mehr Aufwand betreiben willst und dafür auch ein kleines Model schreiben.
Eine Action kann ja schliesslich zu mehreren Views forwarden, da erscheint es mir nicht richtig, die View-spezifischen Daten zentral zu sammeln.
Erstelle doch zwei Datenbanken: Eine für die anwendungsspezifischen Daten und eine für das System. Diese DB speichert dann die View-Daten sowie Konfigurationen oder so was. Wenn du später siehst, dass eine richtige DB totaler overkill ist für eine solche Anwendung, dann kannst du das Model immer noch auf ein FlatFile umstellen.
HTH
Tom2