nicht angemeldet
Hallo Sven,
Objektorientierung hin oder her - solange man die Datenbank nur mit SQL ansprechen kann, muß jegliches Datenbankmodell immer wieder auf einen String zurückgeführt werden. Und aus einem String heraus wieder als Objekt generiert werden.
Im Printip werden aus Tabellen Klassen und aus Datensätzen Objekte. Beziehungen dazwischen werden zu Referenzen. Wenn man natürlich die Antwort eines SQL-Queries direkt in HTML-Ausgabe und Formular-Daten wieder direkt in Update- und Insert-Operationen, dann ist es natürlich kaum sinnvoll, so etwas zu tun. Sinnvoll ist es wohl eher, wenn man so ein Datenmodell für aufwendigere Berechnungen/Transformationen benötigt und es auch nicht nach jedem Request neu aus der Datenbank erzeugen muss sondern durch irgendwelche Session-Mechanismen weiterreichen kann.
Das wirft vor allem die Problematik auf: Wie entstehen die Datenobjekte eigentlich. Ohne existierende DB-Zugriffsklasse funktionieren sie nicht. Wie erhalten sie Kenntnis von und Zugriff auf diese DB-Klasse?
Entweder kennen sie eben alle diese Zentrale Klasse und können eine Instanz davon erzeugen (typischerweise per Singelton) oder sie müssen bei der Instanzierung eben eine Instanz bekommen.
Abgesehen davon haben eigentlich alle Datensätze einer Datenbank irgendwie etwas miteinander zu tun. Man kann nicht einfach so trennen. Bzw. wenn man trennt, dann eigentlich entlang der natürlichen DB-Grenzen: Datensätze und Tabellen.
Eigentlich nur Anhand der Tabellen. Eine Komponente A darf eben die Datenbank nicht derart beeinflussen, dass eine Komponente B, die nichts von A weiß, von diesen Änderungen beeinflusst wird. Damit dürfen sich die Komponenten nicht gegenseitig in Tabellen schreiben und Abhänigkeiten zwischen den Tabellen bedeuten auch Abhängigkeiten der Komponenten.
Und da die Objekte sowieso alle am Skriptende wieder gelöscht werden: Warum nicht einfach genau die Daten aus der DB abfragen, die man braucht, und alle anderen ignorieren.
Das ist natürlich ein Problem. So flexibel Daten auswählen wie mit direktem Datenbankzugriff wird man nie können, wenn man ein Objektmodell dazwischen hat. Allerdings ist der Sinn eines solchen Modells ja auch zu abstrahieren. Man muss sich also eben überlegen, welche Zusammenstellungen von Daten man braucht. Man muss ja keine Modell für alle Daten erstellen.
Bei einem komplexen Objektmodell für Daten hätte ich das Gefühl, dass sich PHP dann die meiste Zeit mit dem Parsen der Klassendefinitionen rumschlägt.
Dass da jedes mal Scripte geparst werden, ist ein Problem von PHP bzw. auch nur mancher Möglichkeiten PHP auszuführen. Das kann man ja auch im Speicher halten. Bei CGI-Anwendungen u.ä. passiert das natürlich nicht, bei anderen Technologien schon.
um dann nur genau eines der vielen möglichen Objekte wirklich anzulegen
Das sollte wie gesagt auch nicht bei jedem Request passieren. Die Objekte müssen dann natürlich im Speicher gehalten oder serialisiert und deserialisiert werden.
mit Daten zu befüllen, in ein Template zu packen und sie auszugeben.
Ja, wenn zwischen Datenbankabfrage und Template praktisch nichts passiert, ist das wie schon gesagt kaum sinnvoll. Eine Shop-Anwendung tut ja aber mehr. Da Werten zumindest Artikel in einen Warenkorb gepackt, möglicherweise kann man Artikel irgendwie konfigurieren etc. Man hat also schon einiges an Information, was nicht in der Datenbank gespeichert wird bzw. erst dann, wenn der Kauf abgeschlossen ist.
Abgesehen davon: Meine Templateklasse kann ganz prima komplette Arrays entgegennehmen und direkt den Platzhaltern zuweisen - ideal bei Datenbankabfragen, bei denen die Feldbezeichner ja als Arrayschlüssel schon enthalten sind und durch Alias-Namen auch frei und fix gewählt werden können. Mit Objekten funktioniert das allerdings nicht. :)
Das ist nur eine Frage der Schnittstellen der Objekte. Ein Abfragen aller Eigenschaftsnamen und deren Werte ist da recht trivial umzusetzen.
Grüße
Daniel