Hallo Petra,
vorab, das für dich speziell und verständlich zu erklären oder gar zu definieren wird schwierig.
MVC ist an sich ein Konzept das jeder Programmierer ein wenig anders ausführt
(Es ist halt ein Konzept).
Ziel vom MVC ist es den Quellcode wartbarer und wiederverwendbar zu machen und vor allem diese Quellcode-Müllhalden weg zu bekommen.
Mega beschi**en sind die WP Schnipsel die hier gepostet wurden. Es wird im Template die Datenbank abgefragt. Wenn du ein 2 Template oder layout baust musst du die Datenbankabfrage kopieren und ins neue Template einbauen. Nun stellst du fest, das die Query nicht optimal ist. Im ersten Template passt du es noch an, im Zweiten vergisst du es.
Vielleicht als bildliche Komponente für solchen Unsinn.
Aufgabe: Weihnachtsplätzchen backen.
Weil man zu faul, zu doof oder irgendwie nicht auf den Trichter kommt, dass es Förmchen braucht, schneidet man die Weihnachtsmänner mit der Schere oder dem Messer aus.
Also, keine Förmchen kein Backen. Struktur muss her.
Wir brauchen einen der Clever ist und sagt das wir Förmchen haben müssen.
Dann einen Sklaven, der die Förmchen kauft, den Teig ausrollt und die Teile aussticht.
Der Tolpatsch fehlt noch, der macht die Schoko Streusel darauf, packt die in die Kiste und bringt die zur Weihnachtsfeier.
Damit haben wir die Arbeit so verteilt, das sich nur einer die Finger schmutzig macht (das Model/Sklave).
Ein Doofer der kleckert und am besten weit von uns weg ist(before er noch Schaden anrichtet), um die Backsachen auszuliefern(view/Doofie).
Einer fehlt noch, der Boss, Sein Job ist es den Beiden anderen zu sagen, was sie tun sollen. Er nimmt auch die Bestellungen für eine weitere Ladung Kekse an(Controller).
...passt das soweit?
Nun das ganze Programmiert(..dies ist nur eine Art der Anwendung des MVC Konzeptes).
Ein User möchte sich über die Webseite einloggen und hat seine Zugangsdaten eingegeben.
Der Boss:
schaut sich die Anfrage genau an.
Validiert die Anfrage und entfernt "Tipfehler" und andere Häggerein.
ist er mit Anfrage zufrieden überlegt er wem er die Anfrage am besten aufbürden kann.
Damit sind wir beim Model(der Boss hatte das Login-Model gewählt und dem Login-Model gesteckt, Username und Passwort)
Das Model:
holt sich die Zugangsdaten für die Datenbank aus der Config
stellt eine Datenbankverbindung her(wenn das nicht klapp petzt er das dem Boss)
nun der eigentliche Job, er vergleicht die vom Boss bekommenen Zugangsdaten mit denen die in der Datenbank liegen.
Endweder findet er die oder eben nicht. Beides erzählt er dem Boss. Wortkarg mit "hab ich nicht, kenn ich nicht" oder "ja kenn ich der heisst so und so, war dann und dann hier....blabla"
Nun muss der Chef entscheiden was zu tun ist.
Hat das Model die Daten nicht gefunden, speise ich den User mit nem krassen "Verboten-Bildschirm" ab.
Sollten der User gefunden worden sein, muss er hofiert werden.
Damit hat der Boss soweit seinen Teil getan und gibt den Kelch an Doofie weiter.
Der hat von allem nichts mitbekommen und kapiert ohnehin nicht. Was er verstanden hat, war "Verboten-Bildschirm ausgeben"
..hier kann er frei entscheiden, je nach Lust und Laune, ob ein Warndreieck oder ein zarter Schriftzug "da war wohl was falsch".
Die etwas anspruchsvoller Aufgabe, wenn der User existiert.
Hier muss sich der View intensiv um die Ausgabe der Daten kümmern, wo kommt was hin. Was hat der Boss gesagt, was ich auf keinen Fall weiter Plappern darf, das darf ich nicht ausgeben.
Für arg doofe hat das Model sicherheitshalber Passwörter und andere sensible Daten aus der Rückgabe entfernt, damit wirklich keiner auf die Idee kommt damit noch Unsinn zu machen.
Damit hätten wir einen Run durch das System geschafft.
Nun zum Sinn, wenn ein Teil davon nicht schon klarer geworden ist.
Der Controller verteilt die Arbeit an seine Untergebenen. Wenn er noch einen Helfer für die Webseiten-Inhalte benötigt, dann ruft er sich das content-model und sagt,
diese Seite brauche ich , also ..fix her damit. Den Controller interessiert auch nicht, wie das jeweilige Model seine Daten beschafft, Hauptsache die werden zurückgegeben.
Das Model oder die diversen Models haben keine Ahnung was gerade los ist. Brauchen die auch nicht. Die Bekommen ne Ziffer und suchen in der Richtigen Schublade dannach.
Die haben die Ãœbersicht über das Lager holen die Teile heraus. Ohne Verpackung und klicki bunty. Nur die Teile!
Nun sollte die Gesamtleistung des Unternehmens MVC noch stimmen. Dafür ist der View zuständig. Er schnibbelt ein paar Bilder mit rein. Positioniert das so, dass Oma Trude die Seite noch lesen kann.
(der Boss gab noch den Wink, das Oma Trude noch mit windows xp unterwegs ist und der Monitor noch schlappe 800x 600 hat).
Die 3 Teile sind also nur bedingt von einander abhängig. Das proggrammiert sich jeder so wie er es braucht oder falls es eine Integration ist, wie es dort üblich ist.
Im Prinzip kann man das Model als Leiharbeiter ins Ausland, in eine andere Firma stecken. Er braucht nur geringe Zeit um Schraube Groß, Schraube klein als Befehl zu verstehen.
Wie so eine Schraube aussieht weis das Model ohnehin und findet sich schnell zurecht.
Mit dem View ist es ebenso. Den kann man auch weiterreichen. Das markanteste sind die Templates die man sich installiert und schon gehts los.
So ist das System relativ unabhängig von einzelnen Teilen und deren Ausprägungen.
... Zum Anfang sollte man sich das Dreiecks-Model aus dem Kopf schlagen, das ist zwar richtig, verwirrt aber nur. Das ist wie das Reste-Schraubenglas..Chaos.
Wichtig ist, dass das Model auschliesslich Daten beschafft und verarbeitet. Ohne jegliche Ausgabe von html!
Der View sollte in keinem Falle anfangen irgendwelche Berechnungen auszuführen. Installiert man sich auf seine Seite ein neues Template, ist beispielsweise die Abfrage nach dem letzten Besuch des User futsch.
Das wäre ein Disaster.
Ich denke hier hilft ganz einfaches Anfagen mit dem Programmieren. Keine tiefen Aufgaben, einfach nur das Mvc strukurieren. Den Controller die $_POST abfangen lassen und daraufhin
das richtige Model ansteuern. Ein paar kleine Models bauen Eins für die Datenbank, Eines welche die Query für die Useranfrage an das Datenbankmodel reicht. Ein Content-model.
Dann einen View der die Verschiedenen Login Zustände abbildet "eingeloggt, ausgeloggt, verboten". Um so ärmer die Teile sind um so leichter lässt sich das lernen und verstehen.
Erst wenn man es ein wenig verstanden hat und bissl Trockenübungen hatte, macht das richtig viel Spass...also viel Freude
Beitrag erstellen
EinloggenKostenlos registrieren