MVC: gibt´s zitierbare Quellen, die beschreiben, dass V nicht auf M zugreifen darf?

[Peter (Gast)]

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

[lowlevel (Gast)]

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

[Peter (Gast)]

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...

[D. I. (Gast)]

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.

[lowlevel (Gast)]

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.

[Stephan M. (stephanm)]

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.