[Basti]

Hi.

Ich steh grad auf dem Schlauch bzw. befürchte, dass es keine gescheite Lösung für mein Problem gibt.

Ich arbeite an einer Anwendung mit Datenobjekten. Die Eigenschaften dieser Datenobjekte werden als Objekte unterschiedlicher Klassen in einem Array im Datenobjekt gehalten.

Nach außen hin ist das aber nicht direkt sichtbar. Ein Aufruf:

$User->password;

gibt eben das Passwort als Zeichenkette aus und nicht das Passwort-Objekt.

Das Ganze ist in etwa so umgesetzt:

PHP-Code:

<?php
public function __get($sProperty)
{
    if (!$this->has($sProperty))
        throw ...

    $Property = $this->getProperty($sProperty);

    return $Property->getValue();
}
?>

Mein Problem jetzt: Ich kann so garkein Interface definieren.

Ich werde aber nicht darauf verzichten, die Attribute als Objekte zu speichern und will auch ungern darauf verzichten, auf die beschriebene Art und Weise direkt auf die Werte der Attribute zugreifen zu können.

Habt ihr da eine Idee für eine Lösung? Funktioniert nicht, oder?

Basti

[Ben]

Ich muss gestehen, dass ich das Problem nicht ganz verstanden habe.
Du kannst kein Interface definieren, weil du ... was?

Warum dann nicht einfach eine abstrakte Klasse verwenden?

[Basti]

Oh, ich hab grad festgestellt, dass ich eh verplant war. Ich dachte, man könne in Interfaces Attribute definieren, geht aber gar nicht.

Ich wollte sicherstellen, dass z.B. ein Objekt die öffentlich zugänglichen Attribute 'id', 'name', ... besitzt und das eben z.B. via if($Component instanceof IPageComponent) prüfen, um die Komponente andernfalls entsprechend zu dekorieren.

Werd ich dann auch genau so erstmal machen - nur, dass die Interfaces eben leer bleiben. verrückte Geschichte...

Basti

evtl. hilft dir das data access object pattern
allerdings bin ich inzwischen eher ein fan von code-generatoren wie z.b. propel. mit einem generator hast du beides: eine explizite schnittstelle und relativ einfache verwaltung.

[Basti]

Ich kann mich mit der Idee nicht anfreunden, mein Datenmodell in XML oder YAML oder so zu definieren. Ich will einfach PHP programmieren und aus den DataObjects, die die Definitionihrer selbst enthalten, ließen sich später ja auch für unterschiedliche DBs DAO-Skelette und die Datenbank generieren.

Mein Entwurf sieht dem "pluggable DAO"-Entwurf in dem Artikel ganz ähnlich. Es gibt keine konkreten DAO-Factories, sondern nur eine, die sich die Info, welches Klasse gebaut werden soll auch aus der Config holt und eben alle DAOs bauen kann. Die beommen dann ein Objekt DataSourceManager mit, aus dem sie sich die jeweilige Datenquelle ziehen können. Und die Handler heißen bei mir auch Manager (UserManager, RoleManager etc.), da sie alle Instanzen ihrer Klasse nicht nur bauen lassen, sondern auch halten und verwalten.

Aber der Artikel hat mich nochmal zu ein paar Änderungen inspiriert. Danke.

Mal sehen ... fertig bin ich noch nicht. Ziemlich knifflig dieses ORM - bei Sicherstellung der Datenintegrität (hoffentlich *g) die Performance irgendwie nicht ganz in den Keller rutschen zu lassen.

Hab mir Propel etc. aber z.B. auch noch nicht von innen angeschaut. Musste mich erstmal from scratch dem Thema nähern.

Basti

Zitat von Basti

Ich kann mich mit der Idee nicht anfreunden, mein Datenmodell in XML oder YAML oder so zu definieren. Ich will einfach PHP programmieren und aus den DataObjects, die die Definitionihrer selbst enthalten, ließen sich später ja auch für unterschiedliche DBs DAO-Skelette und die Datenbank generieren.

verständlich, aber du musst bedenken, wo du die meiste zeit beim programmieren verlierst. das ist nicht beim programmieren selber, sondern bei der fehlersuche hinterher. im prinzip gibt's ja für ORM nur zwei möglichkeiten: implizites arbeiten, d.h. über reflection, konfiguration und einer alles-könnenden klassenstruktur etwas zusammenbauen, was für alle fälle funktioniert, oder explizit - mit fixem code für jeden fall, sei dieser nun generiert oder handgeschrieben.

nachteil des impliziten, reflektiven codes:
* extrem schwer zu debuggen
* die 10% sonderfälle, die immer auftreten - wie werden die abgehandelt?
* um einiges langsamer
* fehler werden erst zur laufzeit sichtbar

nachteil des expliziten codes:
* viel code
* bei handgeschrieben: sehr viel mehr arbeit
aber:
* explizite interfaces
* fehler zur kompilierzeit sichtbar (bei php wurscht, aber trotzdem: lieber ein "fatal error: call to undefined method: getBla()" statt ein leises "return null", wenn man eine datenbank-spalte umenannt hat!)

sondern nur eine, die sich die Info, welches Klasse gebaut werden soll auch aus der Config holt

und wo siehst du den unterschied zwischen einer config.xml, die die tabellen und relationen als xml abbildet und einer config.php, die das selbe macht? xml ist simpel und praktisch.

Mal sehen ... fertig bin ich noch nicht. Ziemlich knifflig dieses ORM - bei Sicherstellung der Datenintegrität (hoffentlich *g) die Performance irgendwie nicht ganz in den Keller rutschen zu lassen.

achte darauf, locking gleich von anfang an mitzuimplementieren und mitzubedenken.

Hab mir Propel etc. aber z.B. auch noch nicht von innen angeschaut. Musste mich erstmal from scratch dem Thema nähern.

unbedingt anschauen. es ist nicht unbedingt _die_ allerbeste lösung überhaupt, es erspart aber viel, viel arbeit.

[Basti]

Zitat von axo

verständlich, aber du musst bedenken, wo du die meiste zeit beim programmieren verlierst. das ist nicht beim programmieren selber, sondern bei der fehlersuche hinterher. im prinzip gibt's ja für ORM nur zwei möglichkeiten: implizites arbeiten, d.h. über reflection, konfiguration und einer alles-könnenden klassenstruktur etwas zusammenbauen, was für alle fälle funktioniert, oder explizit - mit fixem code für jeden fall, sei dieser nun generiert oder handgeschrieben.

nachteil des impliziten, reflektiven codes:
* extrem schwer zu debuggen
* die 10% sonderfälle, die immer auftreten - wie werden die abgehandelt?
* um einiges langsamer
* fehler werden erst zur laufzeit sichtbar

nachteil des expliziten codes:
* viel code
* bei handgeschrieben: sehr viel mehr arbeit
aber:
* explizite interfaces
* fehler zur kompilierzeit sichtbar (bei php wurscht, aber trotzdem: lieber ein "fatal error: call to undefined method: getBla()" statt ein leises "return null", wenn man eine datenbank-spalte umenannt hat!)

Meine Strategie ist die, die Attribute der DataObjects und die Zugriffe darauf in einem abstrakten DataObject zu kapseln - konfiguriert durch die Definition, die die konkrete Klasse eben enthält. Lediglich die Anfragen, die zugeordnete Objekte/Objektlisten zurückgeben sollen, sind "hardcodiert".

Natürlich wäre es eigentlich unnötig, eine eigene Klasse zu abuen, wenn ds Objekt keine solchen Funktionen besitzt und man die Configuration einfach sonstwohin legen könnte. Aber ... wie du auch schon schreibst, brauch ich eben die Interfaces.

Bei den DAOs ist das nochmal anders, allerdings ist das auch ziemlich unsinnig, da es ja praktisch keine DAOs gibt, deren Standard-CRUD-Funktionen nicht erweitert würden, die ja eh ausgelagert sind.

und wo siehst du den unterschied zwischen einer config.xml, die die tabellen und relationen als xml abbildet und einer config.php, die das selbe macht? xml ist simpel und praktisch.

Was hat das mit der DaoFactory zu tun? Hie geht es nur um den Unterschied, ob die Factory alle Daos erzeugen kan, oder ob es für die speziellen Datenquellen eigene, konkrete DaoFactories braucht.

Ich ziehe in der DaoFactory die Infos default_source und default_classnamepattern (z.B. 'Dao_%s') und für jedes Dao können auch extra eine eigene Datenquelle bzw. Klasse definiert werden (ob sich das Config-Objekt diese aus einem XML-Baum oder sonstwoher fischt, ist der Daoactory dabei völlig Wurscht).

Somit bekommt dann jedes Dao seine eigene Datenquelle mitgeliefert.

achte darauf, locking gleich von anfang an mitzuimplementieren und mitzubedenken.

Wie meinst du? Du meinst, ich solle Objekte explizit als "schreibbar" auschecken und die entsprechenden Datensätze in der Datenbank für die Laufzeit gegen Schreibzugriffe durch andere Prozesse schützen?

Ich weiß nicht so recht. Ich denke, das Problem muss eh auf einer anderen Ebene gelöst werden, denn mitunter liegen die Objekte ja auch in der Session und hier geht ein Locking ja mal garnicht.

Basti

PS:
Gab im Sitepoint-Forum mal einen Beitrag, ich glaub von Markus Baker, nicht die DatenObjekte zu speichern, sondern nur die Änderungen zu dokumentieren. Auch interessant...

[Ben]

Zitat von Basti

Gab im Sitepoint-Forum mal einen Beitrag, ich glaub von Markus Baker, nicht die DatenObjekte zu speichern, sondern nur die Änderungen zu dokumentieren. Auch interessant...

Hab den nicht gefunden ... Nur einen weiteren Hinweis auf ihn.
Falls du einen Link hast .. danke.

[Basti]

http://www.sitepoint.com/forums/showthread.php?t=214183

[Ben]

Danke.