OOP / MVC / Routing in Bootstrap-Prozess oder Front-Controller?

[Der-Dennis]

Hey dedlfix,

Oder sie treiben OOP "auf die Spitze", in dem der Name einer Datenbank-Tabelle eine eigene Klasse erhält (also nicht gezwungenermaßen, sondern bei dem, was möglich wäre). Da kann ich auch die "bei-OOP-zuviel-Overhead"-Nörgler verstehen, da für mich nach Kosten-Nutzen-Rechnung mein Argument mit der besseren Wartbarkeit - trotz Caching - verschwindend gering ausfällt.

Ich nehme an, das wird nicht nur Selbstzweck sondern für bestimmte Anwendungsfälle notwendig sein. Du bekommst diese Funktionalität ohne OOP sicher auch nicht ohne vergleichbaren Overhead hin.

dies wird sicher auch ohne OOP der Fall sein, da hab ich mich nicht richtig ausgedrückt. Nur frage ich mich, wo soll dieser Anwendungsfall sein? Mir fällt schlicht und einfach keiner ein, außer dass ich einer Datenbank-Tabelle hin und wieder einen neuen Namen geben möchte und dies dann in nur einer einzigen Datei machen müsste. Aber warum sollte ich das tun? Ich hab eine Tabelle ja nicht zum Spaß "user" genannt!?

Ja, der FC hat nicht nur die Aufgabe des Routings (wie ich ja dann später auch noch sagte), insofern war mein Satz so nicht ganz richtig. Die Hauptaufgabe ist jedoch das Auswerten und Routen des Requests. Inwieweit für den Request mehrere Teilschritte zu erledigen sind, und wer die erledigt, steht auf einem anderen Blatt. Es können durchaus pro Request mehrere Actions von einem oder mehreren Action-Controllern notwendig sein. Wenn deine fertigen Seiten modular aufgebaut sind, könnte eine Action den Hauptinhalt generieren, eine andere kümmert sich um das Werbungs-Modul, und weitere Actions werden für die anderen Module aufgerufen.

Danke, dann habe ich zumindest den richtigen Grundgedanken gehabt. Und meine eigentliche Frage "Routing in Bootstrap oder Front-Controller" hast Du damit vollständig beantwortet :-)

Die Einteilung nach den Pattern ist nicht unbedingt eins zu eins auf Klassen zu übertragen. Es kann durchaus auch sein, dass in (d)einer Implementierung Pattern-Elemente und Klassen nicht aufeinanderfallen - nicht in dem Sinne, dass für ein Element mehrere Klassen benötigt werden sondern, dass Teile der Klassen X und Y für das Patternelement verwendet wurden und die anderen für andere Elemente. Ob das sinnvoll ist? Vermutlich nicht, denn man hat ja nicht umsonst diese Elemente und deren abgegrenzten Aufgabenbereich beschrieben. Also sollten auch deren Grenzen an den Grenzen der Programmierelemente (z.B. Klassen, Namespaces etc.) zu sehen sein.
Das musste ich mir jetzt mehrfach durchlesen, um es zu verstehen. Aber mein Problem ist ja gerade, wo ich die Grenzen ansetzen sollte / muss.

Dazu sollte man generell den Sinn von Pattern und die Historie ihrer Entstehung betrachten. Sie wurden ja nicht einfach am Reißbrett entworfen, sondern jemand hat festgestellt, dass er es sich bewehrt hat, bestimmte Aufgaben immer nach dem selben Muster zu lösen. Diese Muster musste man nur erkennen, sie beschreiben und ihnen Namen geben. Man hat also eine Lösung oder Teile davon beschrieben, und aus der Beschreibung kann man nun wieder eine Implementation für ein anderes System erstellen. Sie werden idealerweise auf dem ursprünglichen System klar und deutlich zu sehen sein und auf den anderen ebenfalls. Aber allein durch die Verwendung eines Patterns ist man nicht verpflichtet, es buchstabengetreu nachzubilden. Man tut jedoch gut daran, es bei starken Abweichungen zur Beschreibung anders zu benennen, sonst ist ein außenstehender Betrachter vermutlich erstmal irritiert. Um dein Abgrenzungsproblem zu lösen, kannst du jedoch dahergehen und dir aus den formalen Beschreibungen der Patterns herauslesen, welche Aufgaben sie usprünglich zu lösen hatten und deine Implementation ebenfalls an diesen Beschreibungen auszurichten.

Das hört sich alles sehr schlüssig an. Heißt also für mich: Lesen! Genau lesen, was warum beschrieben wurde und wie ich es umsetzen kann.

• Anwendung wird aufgerufen: Alle für die Anwendung unabdingbaren "Prozesse" werden initialisiert und gestartet
  Das ist das Bootstrapping - Urladen. Da sehe ich eigentlich nur ganz grundlegende Initialisierungsaufgaben. Der Rest ist dann eher schon Front-Controller.
  Auch hier liegt mein Problem. Nach meinem jetzigen System hätte ich keine Verwendung für das Bootstrapping:
  Das Laden von Konfigurationsdaten und die Initialisierung des Autoloaders finden bei mir beim Aufruf der Anwendung statt.

Du meinst __autoload(), um die Klassen zu laden? Nun, das könnte man ja als Teil des Bootstraps ansehen, denn schon der FC könnte ja in den Genuss kommen, damit geladen zu werden. Und schon hast du einen Bedarf für ein BS. Wie sieht es mit der Angabe, wo die grundlegende Konfigurationsdatei der Anwendung zu finden sind, aus? Die Initialisierung des Fehlerloggings könnte ebenfalls Aufgabe des BS sein. Also alle Aufgaben, die unabhängig vom und vor dem Auswerten des Request gelöst werden sollen.

Ja, ich meine __autoload()... Das wird beim starten der Anwendung geladen, damit beispielsweise der Front-Controller geladen werden kann... Also ab in den Bootstrap!
Und die Fehlerbehandlung (gemeint ist: Weiterleitung auf einen entsprechenden Controller im Fehlerfall)... Das ist bei mir eins der zuvor beschriebenen "plugins", die beim bootstrapping geladen werden, da die Anwendung ja auch ohne Fehlerbehandlung funktionieren würde.
Das Fehlerlogging allerdings ist bei mir wieder im Start-Teil... Ich merke, ich arbeite inkonsistent.

Beispielsweise die Datenbankverbindung wird bei mir - weil nicht immer zwingend erforderlich - über ein Plugin im Bootstrap-Prozess initialisiert.

Warum kann das nicht das Model in Auftrag geben, wenn es eine benötigt?

Macht es ja indirekt. Nur werden die Datenbank-Zugangsdaten vorher ausgelesen und der DB-Klasse mitgeteilt. Erst bei der ersten Anfrage eines Models an die Datenbank wird die Datenbank-Verbindung aufgebaut.

• Bootstrapping: Alle optionalen Plugins, Aufgaben, etc. werden geladen und evtl. ausgeführt
  Ob das noch Bootstrapping ist?
  Das ist die Frage...?! ;-)

Kommt drauf an, was konkret da zu tun ist. Dinge rund um den Request erledigt der FC, Anwendungsinitialisierung macht das BS.

Ich weiß nicht, ob ich zuvor genug beschrieben habe, wie es bei mir zur Zeit ist, dass man das beantworten könnte.

Gruß und vielen Dank, Dennis