Hallo, hab eben mal diesen hier angelesen: http://r.je/views-are-not-templates.html Ich fand die Seite echt gut und verständlich. Auch das "Hello World" fand ich sehr schön: http://r.je/mvc-in-php.html Allerdings sagte mir mein Kollege in der Arbeit, dass hier gegen MVC verstoßen wird... Wer hat denn nun recht? Viele Grüße, Peter
Es wird nicht unbedingt gegen MVC verstoßen, allerdings greift der Controller "direkt" auf die "Daten" im Modell zu. Das ist eher unüblich, da man davon ausgehen sollte das weder View noch Controller die dem Modell unterliegende Datenstruktur (in diesem Fall einen String) kennen. Das Modell bietet normalerweise Funktionen an (was hier overdressed wäre), die einem Controller die Möglichkeit geben Daten zu verändern oder darauf zu zugreifen. Solltest du weitere Informationen zu den Grundstrukturen von MVC suchen schau dir mal die Model-View Architektur von Qt an. Dort nennt man den Controller Delegate aber ansonsten ist die Struktur gleich. Vorteil ist, dass ein Model (hier in C++) immer von QAbstractItemModel abgeleitet wird. Die Funktionen data() und setData() müssen durch den Programmierer eines neuen Modells implementiert werden. Dann kann jede View mit beliebigem Delegate auf das Modell zugreifen auch wenn die Zugrunde liegende Datenstruktur beim Programmieren von View bzw. Controller nicht bekannt war. Gerade dieser Sachverhalt ist die Stärke von MVC. Gruß lowlevel
Hallo lowlevel, ja, Beispiele gibts viele, wo auf MVC gesetzt wird. Aber ich habe das Problem, nicht zu wissen, was denn auf jeden Fall in MVC verboten ist :-( Und das am besten noch aus zitierbaren Quellen...
Vom M aufs V zugreifen ist eher unüblich... Verboten ist schon ein starkes Wort. Aber es gibt noch nen Leitspruch: Fat Models, Thin Controllers Heißt, möglichst viel Businesslogik kommt in die Models.
Hallo Peter, ich denke verboten ist in MVC nichts. MVC ist eher eine Herangehensweise an das Problem (unterschiedliche) Daten sinnvoll zu speichern und darzustellen. Quellen findest du z.B. hier: http://qt-project.org/doc/qt-5.0/guibooks.html#design-patterns dort wird auf Design Patterns verwiesen, was oft in Zusammenhang mit MVC genannt wird.
Die MVC-Anwendungen, die ich so geschrieben habe und schreibe, arbeiten
teils mit Views, die direkt auf das Model zugreiffen und teils nicht.
Beides funktioniert sehr gut, so lange man in der Lage ist, zu erkennen,
wann das eine sinnvoll ist und wann das andere:
- Bei einigen Anwendungen, die ich geschrieben habe, und bei denen das
View direkt auf das Model zugreift, konnte angenommen werden, dass die
Modelle hinreichend simpel, konform mit den "business requirements" und
über die Zeit stabil sind und das auch bleiben werden. Bei diesen
Anwendungen hätte ich Kollegen, die mir weiss machen wollten, dass das
View nicht mit dem business model reden darf, einfach dazu aufgefordert,
die nötige Separation selbst zu implementieren. Spätestens dann, wenn
auch diese Kollegen gemerkt hätten, dass man im Grunde nur bestehende
Datenstrukturen zu 95% kopiert um hier eine vermeintliche "Trennung von
Zuständigkeiten" zu erreichen, wären diese auch still geworden. (Die
letzten 5% sind dann Dinge, die man mit einer Hand voll Hilfsfunktionen
bestens abbilden konnte, ohne dass das irgendeinen negativen Einfluss
auf die Softwarearchitektur gehabt hätte.) Insofern finde ich das Dogma,
dass das View das Model prinzipiell nicht kennen darf (bzw. nicht mit
diesem reden darf) einfach nur quatsch. Das funktioniert an der Uni,
aber nicht im wahrem Leben.
- Speziell bei Web-Anwendungen gibt es bei Verwendung des
MVC-Architekturmusters die Besonderheit, dass eine wesentliche Stärke
von MVC nicht im klassischen Sinne verfügbar ist. In einer
Desktop-Applikation hat man oft das Spiel: Controller verändert Model ->
Model sendet Event über die Veränderung -> das View (das einen Listener
für Veränderungen des Models registriert hat) ändert als Reaktion auf
die Veränderung seine Darstellung. Bei altbackenen Web-Anwendungen ist
diese Reaktion des Views oft nicht in dieser Form möglich, nämlich dann
nicht, wenn der Client (Browser) nur dumpfes HTML-Rendering macht. Bei
modernen Web-Anwendungen, bei denen ein relevanter Teil der Software
clientseitig läuft, hat man aber meist eh kein einfaches MVC-Dreieck
mehr, sondern eher zwei auf eine bestimmte Art und Weise gekoppelte
Dreiecke. Man findet man dann MVC oder verwandte Strukturen sowohl auf
der Serverseite als auch auf der Clientseite. Die Gesamtstruktur sieht
dann so aus: Serverseitig hat man MVC, allerdings ist das View dann ein
Webservice, dass nur noch die aus dem Model extrahierten Daten in irgend
einer Form enthält. Der Client nimmt diese Daten in Empfang, bildet sie
auf das clientseitige Model ab und dann läuft das MVC-Dreieck auf dem
Client weiter. In dieser Konstellation hat man dann ein clientseitiges
View, dass in der Tat nicht mehr mit dem "echten" (= serverseitigen)
Businessmodel redet. Das ist auch ok so und hat unter Anderem den
Vorteil, dass man das clientseitige Modell vom serverseitigen Model
entkoppelt hat und sich insgesamt eine schöne Trennschicht ergibt. Das
geht schon in die Richtung, dass das endgültige (clientseitige) View
nicht mehr mit dem (serverseitigem) Originalmodell redet (es sitzt ja
der Webservice und das clientseitige Model dazwischen.)
- Wenn man nun wieder zur klassischen Desktop-Anwendung zurückkommt,
erhält man eine ähnliche Struktur durch sogenannte Proxy Models. Das
sind Modelle, die unabhängig vom Business Model sind, aber die selben
Daten und Zusammenhänge im Rahmen von den Anforderungen eines oder
mehrerer Views abbilden. Qt schreibt dazu: "Proxy models are components
that behave like ordinary models from the perspective of a view, and
access data from source models on behalf of that view." Das geht ja nun
klar in die Richtung, die Deine werten Kollegen propagieren! Allerdings
bildet ein Proxy Model nicht nur die Daten seines "Source Models" ab,
sondern agiert auch als Mediator zwischen dem "Source Model" und dem
View bezüglich der Events, die das "Source Model" sendet. Damit erhält
man in der Desktop-Anwendung bezüglich der Relation zwischen Model und
View die Struktur: Business Model <-> Proxy Model -> View (<->
Controller). In Web-Anwendungen hilft natürlich auch ein Proxy Model
nicht über die Tatsache hinweg, dass der Weg der direkten
Benachrichtigung (mittels Events) über Änderungen des Business Models
zum finalen (clientseitigen) View nicht möglich ist. Aber wie schon
gesagt: Die im vorangegangenen Abschnitte beschriebene Struktur für
Web-Anwendungen ist in gewissen Grenzen vergleichbar mit dem, was ich
gerade eben für Desktop-Anwendungen beschrieben habe: Das finale
(clientseitige) View hat keinen unmittelbaren Kontakt mehr zum
ursprünglichen (serverseitigen) Model. In der Web-Anwendung entsteht
eine zum Proxy Model ähnliche Struktur durch das serverseitige View
(Webservice) + das clientseititge Model.
- Da man in einer Web-Anwendung ja nun eh nicht die Möglichkeit hat,
Events auf Grund einer Änderung am Business Model direkt an das
clientseitige View zu kommunizieren, kann man Proxy Models gut und gerne
zu einer funktionslosen Datenstruktur verkümmern lassen. Damit nehmen
die Proxy Models genau den Platz ein, den Deine Kollegen ach so gerne
sehen wollen. Was für Web-Anwendungen in der Praxis funktioniert, ist
allerdings für Desktop-Anwendungen eine arge Einschränkung. Dort hat ein
vollwertiges Proxy-Model, dass auch die Mediatorenrolle für Events des
echten Models übernimmt, aus meiner Sicht enorme Vorteile. Proxy Models
erlauben es, View und Business Model ("echtes Modell") voneinander zu
entkoppeln, und dennoch MVC-Anwendungen effizent entwickeln zu können.
- Meine persönlichen Meinung nach hat es sich aus rein praktischen
Gründen selbst rein auf der Serverseite als attrakiv herausgestellt, das
Business Model vom (serverseitigen) View (egal ob das nun eine JSP-Seite
oder ein Webservice ist) zu entkoppeln. Webservices benutzen zumeist
eigene Datenstrukturen, die im Idealfall neutraler als das tatsächliche
Business Model ausgeführt sind (und z.B. per XML Schema vom Architekten
vorgegeben sind). Bei Technologien wie JSP hat man die Risiken, dass
durch diese ineffizient arbeiten, weil z.B. wiederholte teure Abfragen
auf das Business Model passieren, die man besser nur 1x ausführen und
als vorbereitetes Ergebnis zur Verfügung stellen sollte. Außerdem war
und ist der Frontendentwickler schon immer ein Dorn im Auge des
Backend-Enwtwicklers, und der Backendentwickler der gängigen Clichees
hatte noch nie was von all den lustigen aber auch klugen und innovativen
Technologien im Frontendbereich verstanden. Dieses menschliche und auch
die tatsächlichen technischen Probleme haben manche Softwarearchitekten
zum Anlass genommen um das Dogma ausgegeben, dass selbst ein
serverseitiges View nicht direkt mit dem Business Model reden darf (*,
s.u.). Für viele Anwendungsfälle ist das auch absolut sinnvoll, vor
allem in Umfeld von Web-Anwendungen, da hier, wie bereits mehrmals
erwähnt, ein für klassisches MVC eh eine wesentliche Stärke nicht
nutzbar ist, nämlich dass Event, dass direkt oder indirekt (via Proxy
Model) vom Model zum View geschickt wird.
Insgesamt finde ich die auf den vom TO genannten Seiten ausgesprochene
Kritik an bestimmten Entwicklungsmodellen absolut sinnvoll. Eine der
Stärken von klassischem MVC ist die Eigenständigkeit des Views, dass
selbst Herrscher über die Art und Aktualisierung der Darstellung der vom
Model verwalteten Daten ist. Ein Ansatz mit einem Proxy Model, dass als
Mediator zwischen Business Model und einem oder mehreren bestimmten
Views arbeitet halte ich für allemal sinnvoller, als die Datenextraktion
von Modelldaten in die Controller zu stopfen. Bie Web-Anwendungen
verhält es sich meiner Meinung nach etwas anders, da man hier
typischerweise das klassische MVC (mit dem Vorteil von Events vom Model
an das View) nicht 100% zur Anwendung bringen kann. Dem muss man -
zumindest außerhalb der Universitäten - Rechnung tragen durch eine
Anpassung der tatsächlich implementierten Architektur.
Späte Antwort, langer Text :-)
(*) Schuld daran sind für mich als Java-Entwickler unter Anderem auch
die vielen sogenannten "JEE-Tutorials", die einem suggerieren, dass
JSP-Seiten ja ein ach so praktischer Ort sind, um Elemente von Model,
Controller und das gesamte View an einem Punkt zu verschmelzen. Leider
gibt es immernoch Entwickler, die das für voll nehmen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.