php: Model View Controller (MVC)

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