nicht angemeldet
echo $begrüßung;
D.h. also das jede Klasse, die auch nur eine visuelle Ausgabe hat, 3 Dateien hat. Einmal Model wo berechnungen und Queries ausgeführt werden und einmal Views wo alles ausgegeben wird und einmal Controller wo Model aufgerufen und an Views übergeben wird usw...
Das muss nicht so sein. Gegebenenfalls kann man Models oder Views mehrfach verwenden. Natürlich nur dann, wenn die selbe Aufgabe mehrfach benötigt wird. Es sollte nicht so sein dass beispielsweise eine View mal das Kontaktformular und mal Forumsbeiträge liefert. Sie kann aber je nach Anmeldezustand die gewünschte Ausgabe bringen oder auch nur, dass man sich erst anmelden müsse.
Auch ist es nicht so, dass M, V und C immer ein 1:1:1-Verhältnis bilden. Ein Controller kann durchaus mehrere Views bemühen, um die komplette Ausgabe zu erstellen oder je nach konkreter Aufgabenstellung eine unterschiedliche View mit der Ausgabe beauftragen. Es kommt immer darauf an, wie sich die Aufgaben am besten ein übersichtliche Einzelteile separieren lassen.
Es kann sich auch ergeben, dass für die Erledigung der gesamten Aufgabe mehrere Controller-Actions benötigt werden. Wenn die Seite modular aufgebaut ist, kann jedes Modul (Menü, Login-Bereich, Hauptinhalt, News des Tages, Werbung, ...) von einem eigenen Controller (und dessen Actions) behandelt werden und die Ausgaben zusammen eine Seite bilden.
Bei 10 Klassen sind das 30 Dateien.
Und dann pro Klasse ein eigener Ordner?
Meist werden die Klassen in die Ordner Models, Views und Controllers sortiert. Unterordner, beispielsweise um Views zu gruppieren, sind auch möglich. Der Fantasie und Ordnungsliebe sind hier keine Grenzen gesetzt.
Ich empfahl doch schon mal das Zend Framework. Schau mal in den Quickstart, da siehst du unter anderem, wie eine Verzeichnisstruktur aussehen kann.
» »» Also nach die Klassen die hinzukommen werden wie Navigation, Registrierung, Login/Out, Kontaktformular usw.. alles zusammen als EIN MVC Pattern? Alles einzelnd als MVC Pattern?
» Diverse vorbereitende Abläufe sind im MVC-Teil schlecht aufgehoben, weil sie für jeden Controller implementiert werden müssten.
Verstehe ich nicht was du meinst.
Das sollte eigentlich mit dem Nachfolgenden deutlicher werden. Der Prozess der Benutzeridentifikation, so du eine implementieren möchtest, wird für alle Requests benötigt. Bestimmte Aufgaben (Controller und deren Actions) dürfen nicht ohne Autorisierung aufgerufen werden. Diese Prüfungen in die Controller oder Actions zu verlagern bläht diese nur auf und dupliziert vielleicht nicht den gesamten Autorisierungscode aber zumindest die immer gleichen Aufrufe. Stattdessen prüft der Front Controller und leitet die Aufrufe im Nicht-Berechtigt-Fall an einen anderen Controller oder zumindest an eine andere Action weiter.
» Es wird sicher eine Superklasse für alle Controller geben, doch auch da sind diese gemeinsamen Teile fehlplatziert.
Ja es gibt eine Klasse die nennt sich bei mir "loadController" dort werden Requests abgefangen und bearbeitet und die dementsprechende Klasse includet und die gewünschte Methode ausgeführt falls du das meinst.
Das meinte ich nicht damit. Dein loadController wird sicher nicht die Basisklasse für die anderen Klassen sein, die dann von ihm erben (... extends loadController).
»» Als "Türwächter" gibt es dazu einen Front Controller. Der ermittelt nicht nur, welcher Controller aufgerufen werden muss,
Ja das macht mein "loadController".
Dann hast du damit bereits das Front-Controller-Pattern implementiert, ohne dass du es wusstest. (So funktioniert das mit den Pattern. Man kann sie nicht einfach erfinden, man erkennt aus eigener Erfahrung oder der Erfahrungen mehrerer (auch unabhängiger) Entwickler, dass es ein Muster gibt, wie man bestimmte Aufgaben erledigen kann, beschreibt dieses Muster und gibt dem Kind einen Namen.)
» er kümmert sich auch um Authentifizierung und Autorisierung des jeweiligen Requests, denn das muss ja vor dem Controller-Aufruf passieren.
Hm Authentifizierung und Autorisierung sieht bei mir bisher nur so aus das gecheckt wird, ist folgendes vorhanden?: Klassendatei, Klasse, Methode
Das ist keine Authentifizierung und Autorisierung sondern ein Prüfen des Requests, ob dieser eine Aktion verlangt, die es auch tatsächlich gibt. Im Webserver wäre das die Ausgabe einer 404-Meldung, wenn die auszuliefernde Ressource nicht gefunden werden konnte.
» Registrierung, Login/-out und Kontaktformuler sind Aufgaben für Controller.
Ja aber diese Klassen zeigen ja auch das Login Formular und das Registrierungsformular und den Logoutbutton.
Also muss ich auch bei diessen 3 Dateien machen M, V, C.
Nicht immer wird ein Model benötigt und es kann auch Aufgaben geben, die in sich selbständig sind, aber keine Ausgabe erzeugen (Formulardaten waren fehlerfrei, Datenbank wurde aktualisiert und der Client wird mit einem Redirect woanders hingeschickt).
» Wenn du unter Navigation das Erstellen von HTML-Code für Menüs und dergleichen meinst, dann ist das Aufgabe der Views. Die bedienen sich für das HTML-Grundgerüst und gemeinsame Teile der Ausgabe am besten eines Master-Templates.
Oder ergänzend zu dieser Aussage: Wie oben erwähnt kann man einzelnen Modulen auch eigene Controller spendieren, wenn die notwendigen Schritte (Code) zum Erzeugen der Ausgabe umfangreicher werden.
Puh also wirds komplizierter als ich dachte.
Das MVC-Pattern ist ein recht mächtiges Muster. Man kann mit ihm sehr flexibel und einfach erweiterbar eine Aufgabenstellung lösen. Aber Flexibilität kommt immer mit Komplexität daher. Der anfängliche Mehraufwand rentiert sich erst später. (Hinzu kommt noch das Lehrgeld, wenn man wenig Erfahrung mit einer neuen Technik hat.)
Das ist doch viel zu kompliziert!
Oder versteh ich da was falsch?
Einige Schritte implementierst du ja nur einmal. Sie müssen zwar immer wieder abgearbeitet werden, aber das passiert ja ohne dein Zutun, wenn sie einmal fehlerfrei implementiert wurden. Wenn eine neue URL-Verarbeitungsregel hinzukommt, schreibst du die einfach zu den anderen hinzu
/{controller}/{action} - Default-Regel
/{controller}/{action}/{parameter1}/{parameter2} - neue Regel
Der Router im Front Controller perst die Regel, erkennt die Schlüsselwörter controller und action, weiß damit, welche Controller-Action aufzurufen ist und übergibt die ihm unbekannten parameter1 und 2 als Parameter an die Action.
Wenn benötigt: Authentifizierung kann man als Plugin für den Front Controller lösen, wenn man das Zend Framework verwendet, Autorisierung ebenso. Ansonsten kann man das auch anderweitig als abzuarbeitende Schritte des Front Controllers implementieren.
S.o. ich blicke nicht mehr durch... bitte hilf mir.
Vermutlich ist es durch meine Ausführungen nicht besser geworden. Vielleicht gewinnst du die Übersicht wieder, wenn du dir mal eines der vorhandenen PHP-Frameworks nimmst, dein Projekt erst einmal auf Eis legst und dich in die Konzepte dieses Frameworks einarbeitest. Die erscheinen (hoffentlich) in sich einheitlicher als meine mal in die eine, mal in die andere Richtung gehenden Anmerkungen.
Wenn ich mir anscheinend teilweise widerspreche, so liegt das daran, dass es keinen starren Weg zu einer Lösung gibt. Je nachdem, welchen Weg man aus welchen Gründen auch immer einschlägt, ergibt sich die eine oder die andere Möglichkeit als hilfreich zur Zielerreichung.
echo "$verabschiedung $name";