php: Model View Controller (MVC)

[oliver1304]

Guten Morgen liebe Gemeinde,

ich habe eine Verständnisfrage zum Thema: php Model-View-Controller. Es führen ja bekanntlich viele Wege nach Rom aber es gibt immer:

• a: den schnellsten
• b: den längsten
• c: den sichersten
• d: den unsichersten
• e: den mit der mittleren Reisezeit und mittleren Sicherheit
• f: n+1

. <- Satzende

Ich habe nach meinen Recherchen zum MVC verschiedene Ansätze gelesen und für mich interpretiert. Wer agiert hier nun mit wem? Ich kapiere die Logik nur bedingt. Meine Auffassung zum MVC.

Controller: hat eine "Action" bekommen und soll was tun, reicht "übergebene" Daten an das MODEL weiter, bekommt vom MODEL Daten zurück und gibt diese an das VIEW weiter

Model: bekommt vom CONTROLLER gesagt, tu das, tue die, tu jenes und gibt es zurück an den CONTROLLER

View: ohne Logik, macht Schleifen für Arrays, "baut" Templates zusammen, bereitet quasi die Seite (Variablen, HTML, JS) für den USER vor -> und lässt sie über den CONTROLLER in TEMPLATES "schreiben" und ausgeben.

Wo "verstecke" ich den meine Logik? Im Controller oder im Model? Im View denke ich hat die Logik definitiv nix verloren.

Bitte entschuldigt wenn sich der Beitrag schwierig liest, ich stolpere zum erten Mal in die Regionen MVC, Klassen und erreiche meine Ergebnisse durch LearnByDoing.

Danke für eure Hinweise. LG Oliver

[Jonathan Harker]

Hallo oliver1304,

Guten Morgen liebe Gemeinde,

Ich kapiere die Logik nur bedingt.

Im SELF-Wiki gibt es dazu nur wenig:

• wiki.selfhtml.org/wiki/MVC
• wiki.selfhtml.org/wiki/PHP/Tutorials/Templates - erklärt die Trennung von Geschäfts- und Darstellungslogik.

Meine Auffassung zum MVC.

Controller:

hat eine "Action" bekommen und soll was tun, reicht "übergebene" Daten an das MODEL weiter, bekommt vom MODEL Daten zurück und gibt diese an das VIEW weiter

Genau: EVA-Prinzip: Du nimmst Daten, verarbeitest sie und gibst sie weiter.

Model:

bekommt vom CONTROLLER gesagt, tu das, tue die, tu jenes und gibt es zurück an den CONTROLLER

Ja, oder enger gefasst nur die Daten. Sonst musst Du jetzt immer überlegen Datenverarbeitung als MODEL oder als CONTROLLER?

View:

ohne Logik,

macht Schleifen für Arrays,

"baut" Templates zusammen,

Ja

bereitet quasi die Seite (Variablen, HTML, JS) für den USER vor -> und lässt sie über den CONTROLLER in TEMPLATES "schreiben" und ausgeben.

Den Umweg würde ich nicht gehen. Bau ein gutes Template aus HTML; nutze CSS für die Darstellung und bring dann Deine Daten in dieses Template. Das ist der VIEW.

Wo "verstecke" ich den meine Logik? Im Controller oder im Model? Im View denke ich hat die Logik definitiv nix verloren.

Stimmt. Und deshalb würde ich das MODEL nur für die Daten an sich nutzen.

(Edit Rolf B: Bild verlinkt zur Quelle)

Diese Grafik finde ich ganz übersichtlich.

Bis bald! Jonathan

[Rolf B]

Hallo Jonathan,

ich glaube, dass Methodpark das falsch darstellt. Der Controller ist nicht der ständige Vermittler zwischen View und Model.

Das Bild in der Wikipedia zeigt es klarer: Wer kennt wen?

Controller: Kennt View und Model, und bringt die beiden auch zusammen View: Kennt das Model, aber nicht den Controller Model: Kennt nur sich selbst.

Falls eine Kommunikation vom View zum Controller oder vom Model zum View oder Controller erforderlich ist, kann das über ein Notification-System geschehen (z.B. Events oder Callbacks). Das ist in einer länger laufenden Anwendung deutlich relevanter als in der Request-Response Programmierung einer Webseite.

In einer Client-Application oder einer SPA-Website ist es durchaus sinnvoll, dass Modelländerungen automatisch ans UI übertragen werden. Dafür verwendet man UI-Mapper, und Modellklassen, die bei jeder Attributänderung change-Events erzeugen. Ein View kann auch für Aktionen Events auslösen, die der Controller beobachtet und darauf reagiert. Aber das dafür nötige Setup ist aufwändig, weswegen man gut überlegen muss, wieweit man sich für den Server-Code einer Webseite an die reine Lehre hält.

In den WebForms von ASP.NET ist es beispielsweise so, dass jeder POST vom Client erstmal beim Framework landet. Das baut das Server-Gegenstück zur Clientdarstellung auf, und tut dann so, als würde es darauf ein Event auslösen. Fühlt sich beim Programmieren an wie Windows Forms, ist aber ein Hammer an Overhead. Das spätere ASP.NET MVC macht es dann anders, man schreibt Controller-Klassen, die bekommen an Hand der URL Actions. Die GET- und POST-Daten werden vom Framework bereits in Fachklassen umgewandelt, soweit möglich. Und der Controller besorgt die Modelldaten, pflegt die Action ein, speichert die Modelländerungen und erzeugt einen neuen View. Das Erstellen der Action kann man in diesem Bild als einen Teil der View-Schicht auffassen. Und der View ist auf dem Server eben nur ein flüchtiges Ding, das dazu dient, die Client-Antwort zu transportieren. Das kann HTML sein, oder auch XML oder JSON, je nach genutzter Schnittstelle.

Ein solcher View kennt aber eben auch das Modell. Er kann darauf herumnavigieren, Daten zusammenstellen und ggf. aufbereiten, aber nicht ändern. Das macht nur der Controller, auf Grund der Action. An dieser Stelle lässt sich der Code durchaus sortieren. Ein Controller kann beispielsweise dadurch schlank gehalten werden, indem er das Befehlspattern verwendet, d.h. für jede Aktion erzeugt er das passende Command-Objekt und ruft es auf. Dieses Objekt weiß dann, wie die Aktion durchzuführen ist, es weiß bei einer Webseite ggf. auch, wie die Daten aus dem Request zu holen sind, und der Controller ist nur der Manager, der die Beteiligten zusammenbringt.

Rolf

[dedlfix]

Tach!

Es führen ja bekanntlich viele Wege nach Rom aber es gibt immer:

• a: den schnellsten
• b: den längsten
• c: den sichersten
• d: den unsichersten
• e: den mit der mittleren Reisezeit und mittleren Sicherheit
• f: n+1

. <- Satzende

Sicherheit ist kein absolutes Kriterium, das sich einfach so in einem mess- und vergleichbarem Wert ausdrücken lässt. Bei der Frage nach der Sicherheit muss man immer betrachten wofür oder wogegen etwas gesichert werden soll.

Controller: hat eine "Action" bekommen und soll was tun, reicht "übergebene" Daten an das MODEL weiter, bekommt vom MODEL Daten zurück und gibt diese an das VIEW weiter

Wenn die Aufgabe hinreiched trivial ist, muss das Model nicht beauftragt werden. Um zum Beispiel ein Formular mit einfachen Eingabewerten anzuzeigen muss der Controller nur die entsprechende View heraussuchen. Das Model kommt erst dann ins Spiel, wenn Daten benötigt werden, zum Beispiel die Werte für ein Select-Element.

View: ohne Logik,

Es gibt verschiedene Arten von Logik. Die Geschäftslogik behandelt das eigentliche Thema der Anwendung.

macht Schleifen für Arrays, "baut" Templates zusammen,

Das ist auch Logik, Anzeigelogik. Wenn unterschieden werden muss, ob Fehlermeldungen anzuzeigen sind oder nicht, fällt das in den Aufgabenbereich der Anzeigelogik. Die Geschäftsdaten auf inhaltliche Fehler zu prüfen, ist aber Aufgabe der Geschäftslogik. Anhand der Fehlercodes die dazugehörigen Meldungen in der gewünschten Sprache herauszusuchen, ist auch etwas, das in der Anzeigelogik erledigt werden kann.

Wo "verstecke" ich den meine Logik? Im Controller oder im Model? Im View denke ich hat die Logik definitiv nix verloren.

Kommt auf die Art des Themas an. Logik wird überall benötigt. Es ist nicht sinnvoll, zwischen logischen und nicht-logischen Teilen aufteilen zu wollen.

Als Programmieranfänger schreibt man meist einfach so drauflos und macht alles gleichzeitig. Irgendwann wachsen die Projekte und ab da wird es unübersichtlich. Also versucht man Struktur reinzubringen. Dabei wird einem oft gesagt, dass man zwischen Logik und dem Rest trennen müsse. Besonders bei der Ausgabe dürfe keine Logik enthalten sein. Dann fängt man mitunter an, Template-Systeme zu verwenden. Statt PHP beispielsweise steuert man die Ausgabe über Elemente des Template-Systems. Dabei ist man aber nicht die Logik an sich losgeworden, man hat sie nur durch eine andere Syntax ersetzt. Man kann vom Gesichtspunkt der Logik aus auch bei PHP bleiben und foreach und if direkt in PHP lösen. Das Template-System bringt an der Stelle lediglich Komplexität ins Spiel. Diese Komplexität rentiert sich erst dann, wenn weitere Bedingungen hinzukommen. Beispielsweise dass die Templates von anderen Mitarbeitern erstellt werden sollen, denen man (angeblich) nicht ein paar Grundlagen von PHP beibringen kann.

Sinnvoller als die Logik raustrennen zu wollen, ist eine Strukturierung nach Thema. Auch da gibt es unterschiedliche Herangehensweisen. Die einen sortieren nach technischen Gesichtspunkten. Alle Controller auf die eine Seite, alle Views auf die andere, und der Rest in jeweils andere Verzeichnisse. Das sieht zwar ordentlich aus, ist aber meist nicht sonderlich praktikabel, weil man an mehreren Stellen gleichzeitig arbeiten muss, wenn man ein bestimmtes fachliches Thema bearbeitet und dazu die entsprechenden Controller, Models und Views ändern muss. Solange ein System nicht erfordert, dass zum Beispiel Views unbedingt im zentralen Views-Folder zu sein haben, sortiere ich lieber nach fachlichen Gesichtspunkten. Kunden hier, Artikel da, Bestellungen dort, Nutzerverwaltung, etc. pp. Bei einer solchen Ordnung kann es aber auch vorkommen, dass bestimmte Dinge bereichsübergreifend benötigt werden. Dabei kann man sich überlegen, ob man das als eigenes Thema ansieht oder als Helfer, der seine Aufgabe auch ohne fachlichen Hintergrund erledigen kann. Letzteren Kleinkram findet man oft gesammelt in Ordnern mit dem Namen "Shared" oder "Infrastructure".

dedlfix.