php: "reflection" über private member
-
wollt mir mithilfe der php reflection api nen dao manager basteln, der beliebiggestaltige datenstrukturen in ne datenbanks schubst und auch wieder rausangeln kann (dao ohne daos sozusagen ;)). dabei werden auch je nach objekt entsprechende tabellen für die member erstellt, um nicht einfach nen dickes blob reinzukloppen (womit serialize sich ins jenseits schiesst). klappt soweit auch ganz gut, nur hab ich nen problem mit privaten membern von objekten. an die kommt man über reflection leider nicht ran.
hat jemand ne andere schlaue idee, wie man sowas bewerkstelligen könnte? hab das gefühl, ich muss meinen super generischen manager in die tonne kloppen und doch auf standardpattern zurückgreifen.
-
Der Sinn von private Elementen ist nunmal, dass man an sie nicht ran kommt. Deshalb hat man idR eine export() Methode in der Klasse.
Aber was genau ist an serialize schlecht?
-
Shade Of Mine schrieb:
Aber was genau ist an serialize schlecht?
dass man keine anständigen modelle in der datenbank hat, sondern schlicht blobs. naja, im fall von serialize strings. das klammert datenbanklogik aus, find ich schade.
hab mir jetzt aber mal angeguckt, was serialize so erzeugt. das ließe sich gut parsen. muss ich mir nur mal überlegen, ob mir die performanceeinbuße eines parsers das wert ist. glaub ich werds doch wie gehabt über per skript generierte models machen.
-
Und was ist nun so viel besser daran, wenn du für jedes Klasse eine eigene Tabellenstruktur erzeugst, als wenn du sie einfach serialisierst? Ich meine, dafür ist die Funktion schließlich da ...
-
performance einbussen eines parsers...? Weisst du wie lahm Reflection ist...?
Objekte in einer DB abbilden ist meistens nie gut möglich, da die Beziehungen der einzelnen Objekte zueinander sehr schwer zu ermitteln sind. Was dagegen gut geht ist eine DB Struktur mit Objekten abzubilden - da man über die DB Struktur mehr weiss und sie deutlich simpler ist.
Wenn ich Objekte in eine DB packen will, dann serialisiere ich idR denn ich will das Objekt speichern. Das ist ein grundlegender Unterschied zum Abbilden der Objektstruktur. Bedenke dass man anhand Referenzen kaum auf die 3. Normalform kommen können wird ohne _alle_ Objekte zu betrachten die je existieren werden.
-
reflection ist lahm? wer hat den blödsinn denn implementiert? php ist ne interpretersprache, reflection sollte so schnell wie native methodenaufrufe sein. hätte vielleicht mal bisschen über die api lesen sollen, bevor ich sie einfach verwende.
die unförmigen objekte müssen ständig nach bestimmten eigenschaften gefiltert werden, die sich durch ihre member definieren. wenn ich die viecher jetzt als serialized string in die datenbank packe, kann ich mir den vorteil einer relationalen datenbank nicht mehr zunutze machen, sondern muss meine objekte erstmal umständlich "entpacken" und dann eigene suchroutinen implementieren. das blöd *G
und den umgekehrten weg wollte ich mir sparen, um jederzeit neue objekte hinzufügen zu können (was passieren wird). die grundidee war, diesen manager einmal zu schreiben und dann speichern ein für alle mal zu vergessen. einfach munter neue klassen hinzufügen und in die DB stopfen. spart außerdem ne menge hilfsklassen und somit etliche zeilen (generierten) code.
-
thordk schrieb:
reflection ist lahm? wer hat den blödsinn denn implementiert? php ist ne interpretersprache, reflection sollte so schnell wie native methodenaufrufe sein. hätte vielleicht mal bisschen über die api lesen sollen, bevor ich sie einfach verwende.
Äh... Was hat das eine mit dem anderen zu tun?
die unförmigen objekte müssen ständig nach bestimmten eigenschaften gefiltert werden, die sich durch ihre member definieren. wenn ich die viecher jetzt als serialized string in die datenbank packe, kann ich mir den vorteil einer relationalen datenbank nicht mehr zunutze machen, sondern muss meine objekte erstmal umständlich "entpacken" und dann eigene suchroutinen implementieren. das blöd *G
dann eine gemeinsame basisklasse oder ein export() interface?
und den umgekehrten weg wollte ich mir sparen, um jederzeit neue objekte hinzufügen zu können (was passieren wird). die grundidee war, diesen manager einmal zu schreiben und dann speichern ein für alle mal zu vergessen. einfach munter neue klassen hinzufügen und in die DB stopfen. spart außerdem ne menge hilfsklassen und somit etliche zeilen (generierten) code.
und wie passen die objekte in die db struktur rein? Da müssen sie doch gewissen anforderungen entsprechen, oder? Dann sind wir wieder bei dem schönen export interface.
mir ist aber aktuell nicht klar wie du unterschiedliche objekte in die gleiche datenstruktur pressen willst...
-
Shade Of Mine schrieb:
mir ist aber aktuell nicht klar wie du unterschiedliche objekte in die gleiche datenstruktur pressen willst...
will ich doch gar nicht, wo hast du das herausinterpretiert? ^^ ich habe unterschiedliche datenstrukturen, die sich teilweise überlappen, teilweise selbst enthalten und teilweise auch unabhängig sind. aber alle sollen sie in dieselbe datenbank geschmissen werden.
wenn ich jeder klasse ein "export interface", wie du es nennst, spendier (handgedengelt oder automatisiert), bin ich wieder genau da, wo ich weg wollte.
-
thordk schrieb:
will ich doch gar nicht, wo hast du das herausinterpretiert? ^^ ich habe unterschiedliche datenstrukturen, die sich teilweise überlappen, teilweise selbst enthalten und teilweise auch unabhängig sind. aber alle sollen sie in dieselbe datenbank geschmissen werden.
warum dann nicht ein objekt den datensatz representieren lassen? dann kannst du dir teile der objekte generieren lassen und hast kein problem mit irgendwelchen komischen exports.
die sache ist doch die:
die objekte haben vordefinierte regeln an die sie sich halten müssen, oder? sie repräsentieren einen teil der daten. die frage nun ist: welche unterschiedlichen operationen erlauben sie auf den daten und warum hast du soviele unterschiedliche klassen?sobald du den datensatz auf dem die objekte operieren auf einen gemeinsamen nenner bringst, hast du eine basisklasse die du super in die db schreiben kannst.
erklär mal etwas genauer wie das mit den objekten und den daten in der db aussieht. ist die datenstruktur fest oder ändert sie sich mit neuen klassen? wenn sie fest ist: wodurch unterscheiden sich die einzelnen klassen, etc.