nicht angemeldet
Hallo!
- Ich pfeiffe auf die saubere Trennung und baue mir in den SELECT auf die Bildertabelle noch zusätzlich (ganz pragmatisch) die Abfrage über die Anzahl der Kommentare ein. Hätte den Vorteil, dass es schnell geht; hätte den Nachteil, dass da nix mehr von wegen sauberer Trennung wäre. (unelegant, doof)
ja, das ist doof.
- Mir ist Geschwindigkeit egal und ich hole mir dann einfach in der Programmlogik [1] einzeln für jedes Bild die Anzahl der Kommentare. (langsam, unelegant, doof)
ja, auch doof ;-)
- Ich schaffe eine Art "Interface" zwischen den beiden Klassen, bei dem die eine Klasse die andere Klasse zu Hilfe nehmen kann, wenn der SELECT zusammengebaut wird. Will heißen: Die Funktion 'getList' der Klasse (nennen wir sie mal hier) 'GalerieBild' bekommt ein Objekt der Klasse 'Kommentar' mitgeliefert. Dieses Objekt wird dann verwendet, um den SELECT vollends zusammenzubasteln. Und genau da bleibe ich stecken. Hat da jemand eine Idee, wie das realisiert werden kann?
Ich würde hierfür einfach eine Deine Datenbankzugriffsklasse verwenden. Was genau soll diese Klasse in Deinem Konzept machen?
Wie genau holst Du Dir in Deiner Programierlogik die Liste mit den Bildern? Ich würde es als Array machen. Also so eine Methode wie fetchImageList(), die dann wie in Deinem 1. Vorschlag die Bilder aus der Db holt, und als ordneltich formatierten Arrray zurückgibt, eben mit den Kommentaren.
Du könntest auch eine Klasse "Bild" verwenden, die als Eigenschaft die Anzahl der Kommentare hat. Du könntest die Bilder dann über einen Array $bilderListe mit den einzelnen Bild-Objekten als Elemente speichern. Wenn Du sowas machst, kannst Du das entweder direkt in der Programmierlogik machen, oder über eine abstrakte Klasse, die dann mit Hilfe der Datenbankzugriffsklasse und die Bild-Objekte erzeugtm und den Array mit den Objekten zurückgibt. Du rufst also auf
$bilderListe = BilderListe::getList();
Diese getList() Methode könnte dann über eine Methode der Datenbankzugriffsklasse, vielleicht auf getList() eine Liste als Array bekommen, und würde die dann in einer Schleife einen Array mit Bild-Objekten erzeugen, indem sie die jeweiligen set*() Methoden der Bild-Klasse verwendet.
Gut, das könnte auch die Datenbankzugriffsklasse machen, aber eigentlich solte die nichst von den anderen Objekten wissen.
Ist alles eine Frage wie komplex das ganze wird/werden soll.
Achja, Galerie und Kommentarfunktion sind mein aktuelles Problem, ich suche natürlich nach einer generischen Lösung. Will heißen: Ich möchte das ganze auch noch ausdehnen, dass ich im Prinzip auch noch die Benutzerklasse mit einbauen kann: Dass ich also beim SELECT gleich auch noch die Daten über den Benutzer, der das Bild eingestellt hat, mit hole. Die Möglichkeiten eines derartigen Interfaces wären grenzenlos. (daher suche ich auch nach einer Idee für so etwas)
Gut, diese Information hast Du ja in der Tabelle gespeichert, wäre also ein leichtes die mit auszulesen und als Eigenschaft der Bild-Klasse zu verwenden. Dann bräuchtest Du eigentlich nich eine Klasse "Benutzer", in der Du die Daten der Benutzers speicherst.
Wenn Du dann von dem den Namen auslesen willst, dann könntest Du das ebenfalls in der gleichen Query machen wie oben, und den Namen als Eigenschaft in die Bild Klasse schreiben, aber das halte ich nicht für so Sinnvoll. Ich würde eher eine Referenz auf das Benutzer-Objekt in der Bild-Klasse speichern.
Ich persönlich halte es schon für sinnvoll eine abstrakte Klassenmethode zu verwenden, um eine ganze Reihe von Objekten zu erzeugen. Das ist halt immer ein Trade-Off, ein extrem sauberes Design kostet meist Performance. Du könntest aber auch eine abstrakte Klasse "Galierie" verwenden, und darin eine Methode aufrufen, die einen Array aus der Datenbankzugriffsklasse, welche dann eine otpimierte SQL-Abfrage verwendet, erhält, und entsprechend Bilder und Benutzer-Objekte erzeugt. Du musst die Objekte ja nicht immer vollständig füllen, sondern nur mit den Eigenschaften, die Du brauchst.
[1] Die durchaus etwas von den unterschiedlichen Zugriffsklassen wissen darf - ich möchte *ausschließlich* innerhalb einer Ebene trennen!
Das verstehe ich jetzt nicht. Was ist denn "eine Ebene"?
Grüße
Andreas