nicht angemeldet
Hi!
class Application_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract
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.
Mir ist allerdings durchaus bewusst, dass die Klasse Zend_Db_Table_Abstract viele weitere Funktionalitäten beinhaltet. Aber, wo wir gerade dabei sind, mir kommt auch diese Klasse, also Zend_Db_Table_Abstract, reichlich "aufgebläht" vor.
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.
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.
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.
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.)
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.
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.
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.
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.
Ein Fehlerlogging-Mechanismus sollte unabhängig von der Anwendung arbeiten. [und alle Fehler protokollieren können] Also sollte der Loggingmechanismus (wenn nicht schon außerhalb PHPs konfiguriert) als eine der ersten Amtshandlungen des BS initialisiert werden.
Das mache ich erst im Bootstrapping, da mir erst hier die Konfigurationsdaten zur Verfügung stehen (in einer ini-Datei steht beispielsweise, wo sich das error-log befindet).
Da besteht, Deinem vorherigen Absatz nach zu urteilen, allerdings Nachholbedarf. Ich sollte es wohl ganz an den Anfang der Anwendung packen.
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.
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.
Lo!
Struppi