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

[Der-Dennis]

Hey dedlfix,

Hierbei ist es so, dass die Klasse lediglich den Namen einer Datenbank-Tabelle enthält.

Ja, das ist aber nur der einfachste Anwendungsfall. Du hast mit der Klasse nun die Möglichkeit weitere Funktionalität hinzuzufügen.

prinzipiell ja (siehe aber bitte auch den nächsten Absatz).

Zend_Db_Table_Abstract stellt ja seine Funktionalität mehr oder weniger auf allgemeinem Level zur Verfügung. In deiner konkreten abgeleiteten Klasse kannst du nun Methoden hinzufügen, die beispielsweise den Code für bestimmte Abfragen enthalten. Und somit hast du nicht nur Overhead sondern einen Mehrwert.

prinzipiell auch hier ja. Allerdings ist das meiner Meinung nach im speziellen Falle des Zend-Frameworks nicht so sinnvoll, da dort vorgeschlagen wird, man solle die Datenbank-Abfragen, etc. (also zusätzliche Funktionalität) in einem Mapper machen. Damit bräuchte ich die Db_Table nicht mehr erweitern.

Wie bereits gesagt, bei den vorhandenen Frameworks haben sich viele Leute lange Zeit Gedanken drüber gemacht, aber meine derzeit (vielleicht naive) Meinung ist, dass man dies alles wesentlich "schlanker" gestalten könnte.

Ja, sicher. Man kann jedoch auch einfach die Teile ignorieren, die man nicht benötigt. Sie zu löschen ist wegen irgendwelcher Abhängigkeiten vielleicht keine gute Idee. Wenn man das aber gefahrlos hinbekäme, würde auch das Framework wieder schlanker wirken.

Das stimmt wohl, ändert aber nichts an den sehr umfangreichen Klassen an sich. Aber, das hatte ich ja bereits gesagt, wirst Du recht haben, dass man nach und nach zu eben jenem Punkt kommt.

Und eine abgeleitete Klasse nur wegen eines Tabellen-Namens? Für mich ist dies nach meinem OOP-Verständnis zwar folgerichtig, geht allerdings etwas zu weit.

Das ist lediglich die Grundlage. Aber auch in dieser einfachsten Form kann das schon von Vorteil sein, denn man hat nun einen eindeutigen Klassennamen, den man für Type Hinting verwenden kann.

Da habe ich noch gar nicht drüber nachgedacht. Das ist wirklich ein guter Punkt!

Außerdem, der Punkt fällt mir grad noch ein: Die aktuell mir bekannten Frameworks bieten viele, ich nenne sie mal "Komfort-Methoden", die meiner Meinung nach nicht sein müssten.

Kommt drauf an. Ich hab in meinem Haus einen Aufzug, den ich nicht verwende, weil ich zu Fuß meist schneller in der vierten Etage bin. Dennoch ist er beispielsweise für Lasten wie Einkäufe nützlich und ich würde ungern in ein Haus ohne Aufzug ziehen. (Schon für einen Umzug ist er eine enorme Erleichterung.)

Schön beschrieben! :-)

So kann ich einen beispielsweise einen DB-SELECT direkt als SQL-Statement ausführen oder die Funktion select()->from()->was-auch-immer ausführen.

Dazu musst du aber den konkreten SQL-Dialekt beherrschen, wissen, wie man im Speziellen Quotierungen und Maskierungen vornimmt - im Allgemeinen also eine Menge Wissen über das DBMS mitbringen. Das ist eigentlich nicht verkehrt, aber wenn du mehr der Programmierer als der Datanbankspezialist bist, wirst du vermutlich mit den Abstrahierungen des Layers besser zurecht kommen - weil sie, wenn sie gut umgesetzt wurden, doch eher aus der Programmierersicht denn aus DB-Admin-Sicht funktionieren.

Das sehe ich ein. Kurze andere Frage: PDO vs. Zend-Db? Kann mir jemand kurz und knapp sagen, warum ich das eine oder das andere favorisieren sollte? Im Endeffekt baut Zend-Db doch nur PDO nach, oder?
Ich nutze zur Zeit ausschließlich PDO. Oder besser gesagt: Eine eigene Datenbank-Klasse, die PDO erweitert.

Hinzu kommen viele Factory-Methoden (oder Konstruktoren), die ein Objekt, ein Array, einen String oder einen Integer entgegen nehmen können und innerhalb dieser Methode dann entscheiden, "was ich gemeint habe".

Ja, das ist der PHP-Weg. Geht nicht anders bei der Art der Typisierung. In typsicheren Sprachen (wie C#) sieht der Kompiler, welche der überladenen Methoden zum übergebenen Typ passt und ruft diese gezielt auf. PHP muss/[kann erst] zur Laufzeit ermitteln, welcher Typ vorliegt und dann unterschiedlich handeln.

Ich meinte eigentlich etwas anderes: Ein Beispiel, was ich mit "Komfort-Methoden" meine. Sagen wir, ich möchte ein Plugin laden. Das kann ich so laden

  
$plugin = new Plugin_Test();  
$application->loadPlugin('test');  
$application->loadPlugin(0);  
$front->loadPlugin('test');  
$front->loadPlugin(0);  
$front->plugin->test;  
$config->plugin->test;  

und so weiter. Auch wenn das überspitzt ist, lade ich in alle der vorherigen Fälle das gleiche Plugin (Voraussetzung: Das Plugin namens "test" ist im Stack an Stelle 0).
Mein Problem hierbei ist, dass ich es an verschiedenen Stellen der Anwendung immer wieder anders machen könnte, sodass es nachher unübersichtlich wird. So habe ich zum Beispiel vergessen, wie etwas gemacht wird und schaue in der Doku nach. Dort kann ich mir irgendeinen Fall raussuchen. Der nächste, der dann den Quellcode sieht, versteht dann doch "die Welt nicht mehr".
Noch schlimmer dürfte es werden, wenn mehrere Entwickler am gleichen Projekt arbeiten.
Ich hoffe, es ist einigermaßen rübergekommen, was ich meine.

Mir würde es (in den meisten Fällen) vollkommen reichen, wenn eine Methode ein Objekt eines bestimmten Typs entgegen nimmt. Dies ist ja bereits mit PHP möglich, auch wenn es noch kein vollständiges type hinting unterstützt (was ich persönlich bevorzugen würde).

Geht aber nicht mit den doch deutlich öfter verwendeten skalaren Datentypen.

Ja, leider. Aber auch hier meinte ich - wenn auch etwas verunglückt ausgedrückt - das gleiche wie im vorherigen Absatz.

Fehlerbehandlung ist Sache der Programmteile. Dafür kann es sinnvollerweise keinen globalen Mechanismus geben. Zu vielfältig sind mögliche Ursachen und Reaktionen.
Ok, da habe ich mich falsch ausgedrückt. Bei mir werden im Bootstrap-Prozess mittels set_error_handler() und set_exception_handler() die Klassen initialisiert, die "aufgefangene" Fehler verarbeiten und je nach Umgebung (development, testing, production) unterschiedlich handeln.

Ja, als allerletzte Möglichkeit für nicht vorhergesehene Fehler. Letzlich sollte jedoch das Ziel sein, dass dieses Auffangbecken niemals benutzt werden muss, und die Anwendung von sich aus mit den Fehlersituationen umgehen kann. Der allgmeine Error-Handler kann ja eigentlich nur das Script abbrechen, weil er nicht weiß, welche Konsequenzen ein Fortsetzen haben kann. Und Abbrechen sieht in der Regel unschön aus Anwendersicht aus.

Das ist richtig. Kann ich nichts mehr hinzufügen :-)

In den BS-Teil würde ich nur allgemeine Dinge nehmen, die man mehr oder weniger für jede Anwendung braucht. Anwendungsspezifisches, wie Plugin-Initialisierungen oder DB-Layer-Konfiguration würde ich in den anwendungsspezifischen Teil bringen, also als Aufgabe des FC.

Wie zuvor schon: Das beantwortet meine Frage. Dahingehend muss ich meine Entwürfe noch einmal überarbeiten.

Wenn du allerdings Skalierbarkeit wie beim HMVC-Ansatz als ein Ziel hast, solltest du dir überlegen, ob du diese Anhängigkeiten vom FC (und BS) nicht lieber beseitigst.

Ja, das muss ich mir wirklich überlegen. Aber so ganz sicher bin ich mir im Moment noch nicht. Schön wäre es natürlich, wenn Abhängigkeiten möglichst vermieden werden. Das ist auch mein Ziel. Wie ich aber die Abhängigkeiten von BS und FC beseitigen könnte, ist mir grad noch - trotz des guten Artikels - ein Rätsel.

Gruß, Dennis