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

[dedlfix]

Hi!

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.

Wenn du schon fertig bist mit dem Routen, dann kennst du ja schon den aufzurufenden Action-Controller und hast keine Aufgabe mehr für einen Front-Controller.

So war es bei mir bis jetzt ja auch. Also, dass der Front-Controller das Routing übernahm.
Aber eine Aufgabe hätte der Front-Controller noch immer: Er ist die oberste Controller-Instanz. Nachdem er einen speziellen Controller aufgerufen hat, könnte dieser Controller ja noch einen anderen, speziellen Controller für eine Aufgabe benötigen. Der sollte allerdings nicht direkt, sondern über den Front-Controller aufgerufen werden, damit dieser die Entscheidung treffen kann, ob dies überhaupt möglich ist. Außerdem hatte mein Front-Controller die Aufgabe, die Response zu senden (also Header und anschließend die View).

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.

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.

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

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?

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

Lo!