Sponsored Links |
|
|||
Zitat:
Der Controller soll meines Erachtens nach festlegen, was angezeigt wird (Welches View) und welche Daten ihm zur Verfügung gestellt werden. So kann man dem View Daten abhängig vom Benutzer-Status übergeben, während diese Entscheidungen, was in meinen Augen zur Logik gehört, sonst im View getroffen werden müssten.
__________________
... Meine Meinung |
Sponsored Links |
|
||||
Nö.
Das View muss nur die Models kennen. Und welche Daten der Benutzer sehen darf wird (bei mir) ebenfalls im Model entschieden. Wobei .. OK, das View muss den Controller kennen. Ich kann ja mal kurz etwas genauer beschreiben, wie es bei mir ist. Die View-Schicht wird bei mir durch eine Template-Klasse gebildet. Verschiedene Views sind dann halt verschiedene Templates. Die Template-Klasse wird natürlich mit einer Referenz auf den Controller (bei mir Anwendung) erzeugt. Diese Referenz wird benötigt, um die Umgebungsvariablen im Template zur Verfügung stellen zu können, also so Dinge, wie SessionID, UserID, Request-Variablen, etc. Weiterhin gibt es im Controller (oder Anwendung) eine Methode "getModule", welches eine Instanz des per Namen übergebenen Moduls zurückliefert. Die Template-Engine besitzt einen Tag "< x_call call="Package::Module::action" param="..." var="..." / >", worüber sich das Template die Daten beschaffen kann, die es benötigt. Das Template an sich hat also keinen (direkten) Zugriff auf den Controller (bzw. die Anwendung), der Zugriff erfolgt stets über spezielle Tags. |
|
||||
Ich glaube hier herrscht noch eine gewisse Unklarheit, was MVC denn nun konkret ist. Sicher, es gibt viele Varianten, aber eigentlich ist MVC (wie der Name schon sagt) aufgeteilt in
Was du benutzt nennt sich in aller Regel ein Frontcontroller. Also eine zentrale Instanz, die die Usereingaben an Actions delegiert, die wiederum für sich eigene Logik enthalten. Wie die Controller letztendlich aussehen, ist Ermessen des Programmierers. Gängig ist es, eine Klasse zu erstellen, deren Methoden Actions darstellen. Die Variante jede Action in eine Klasse zu schreiben ist auch möglich, wenn auch nicht immer ganz üblich. Wichtig ist nur, dass du mit konsequentem Interfacedesign arbeitest. Wenn du keine klaren Schnittstellen implementierst, hast du kein konsistentes und sauberes Design, was zwangsläufig in einer Spaghetti-API endet. Vor der Implementierung von Klassen sollte man diese mit ihren Beziehungen und Abhängigkeiten auf jeden Fall skizzieren und dabei nach dem Domain-Model-Pattern vorgehen, also reale Objekte und Abläufe in der Programmstruktur darstellen. Nur so ergeben sich sinnvolle Klassen. Klassen haben nämlich durchaus eine semantische Bedeutung und sind nicht bloß nichtsaussagende Container für irgendwelche Methoden. @protonenbeschleuniger: damit sollte sich deine Frage auch beantwortet haben. OO bedeutet Kapselung, Abstraktion der realen Welt im Programmcode und dadurch Wiederverwendbarkeit. Wenn du an zwei Teilen deines Programms die gleiche Logik implementiert hast, ist dein Design fehlerhaft. |
|
||||
Zitat:
Hat das View nun direkten Zugriff auf das Model oder nicht? Afaik wird der Controller irgendwann aufgerufen, dieser wiederrum beschafft sich die Daten von diversen Models und modifiziert diese ggfs. Und ebenfalls der Controller erzeugt die Views und versorgt diese mit den Daten, die er sich vorher von den Models geholt hat. Also: Erlaubt: Controller -> Model Controller -> View Nicht erlaubt: Model -> Controller View -> Controller Model -> View View -> Model wobei "->" für eine Zugriffsmöglichkeit stehen soll. Eine Frage (ernst gemeint): Stellt eine Rechteverwaltung eine Business-Logik für Dich dar? Falls ja, dann dürfte diese ja nicht ins Model, aber warum sollte diese nicht im Model implementiert werden, wenn es dort an zentraler Stelle doch am meisten Sinn ergeben würde? |
|
||||
Ich denke, ich habe mir nicht widersprochen. Die Reihenfolge ist vielleicht nur etwas unglücklich gewählt, aber ich wollte es in der Reihenfolge MVC abwickeln.
Konkret: Model ist passiv, Controller modifiziert Model, View stellt Model dar. Da ist kein Widerspruch drinnen. Es gibt verschiedene MVC-Implementierungen, die alle mehr oder weniger mit MVC zu tun haben. Manche sind gute Weiterentwicklungen manche aber auch einfach nur Missverständnisse. Ursprünglich ist der Controller die Benutzerschnittstelle und das View die eigenständige Ausgabeeinheit. View und Controller werden manchmal auch zusammengefasst. Gängig in Webapplikationen ist die von dir beschriebene Variante, dass der Controller das View auswählt. Das ist in dem Sinne zwar nicht mehr MVC aber durchaus üblich. Dennoch ist das View weiterhin eigenständig und stellt das Model dar. Dies ist in keinem Falle Aufgabe des Controllers. Eine Rechteverwaltung ist eine Architektur, keine Businesslogik. |
|
||||
@Manko10
Das stimmt so nicht, das MVC-Pattern „erlaubt“ auch ein aktives Modell, bei Webanwendungen ist das allerdings selten zu finden (bei Skriptsprachen wie PHP macht es eh keinen Sinn, da der Status zwischen zwei Requests sowieso verloren geht). Ich finde diese Erklärung hier sehr umfangreich und gut gelungen: Model View Controller [Web Application Component Toolkit] @mantiz Die View darf auf das Model zugreifen, allerdings nur lesend, sie darf das Model nicht verändern. |
|
||||
MVC ist in Smalltalk entstanden und hat eine sehr feste »Spezifikation«. Durch die Portierung auf andere Sprachen sind diese Grenzen aber verwischt.
Ganz so aktiv ist das »Active Model« übrigens auch nicht. Es nimmt Daten entgegen und benachrichtigt dann den Observer, es implementiert aber in keinem Falle selbst Businesslogik. Zum ursprünglichen MVC kann ich dir folgendes Openbook empfehlen: Galileo Computing :: Praxisbuch Objektorientierung – 8.2 Die Präsentationsschicht: Model, View, Controller (MVC) |
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Frage zu Mvc | rs-web | Serveradministration und serverseitige Scripte | 9 | 15.11.2010 17:01 |
Habe ich MVC richtig verstanden? | Schneemann | Serveradministration und serverseitige Scripte | 0 | 09.01.2007 02:15 |
Zeilenüberlappung bei margin-top mit negativem Wert | c.weber.os | CSS | 15 | 15.10.2005 16:11 |