Jan 01
Fortschritt, Probleme: OR-Mapper
Ich bin nicht untätig in den Ferien, wobei ich mich allerdings eher der Schule widmen sollte, als meinem Projekt hier…
Die letzten Tage habe ich erste Tests meines Pseudo OR-Mappers (ObjektRelational) gemacht und bin auf ein bzw. mehrere Probleme gestoßen, die ich leider nicht so leicht ausräumen kann.
Ich wollte in einem einfachen Ansatz einer ORM ähnlichen Struktur Objekte um Arrays „mappen“ und einen Mechanismus einbauen der ein automatisches Update ermöglicht, das heißt Veränderungen in den Objekten würden ohne weiteren Codeaufwand selbstständig in die Datenbank geschrieben.
Dabei sollte das Array im Objekt versteckt (private) werden, die einzelnen Eigenschaften (protected) sollten auf Werte des Arrays referenzieren. Diese PRIVATE <-> PROTECTED Relation ist nicht möglich – was auch logisch erscheint, wenn man darüber nachdenkt. Ich werde mir was anderes einfallen lassen.
Gleichzeitig informiere ich mich über OR-Mapper im Allgemeinen. Und stelle fest, dass mein Entwurf lange nicht alle Fähigkeiten der ganzen Idee deckt. Aber das möchte ich gar nicht. Ich versuche ein leichtgewichtiges Basisgerüst zu schaffen. Ich hoffe bald zu den JS Templates übergehen zu können, aber vorher wird es ein erstes Release geben. Damit etwaige interessierte Entwickler erste Schritte mit dem Aufbau machen können.
März 3rd, 2009 at 17:36
Schau dir bezüglich des automatisierten mappens von Objekten doch mal das Unit of Work Pattern an. Das hilft dir nicht nur dabei deine DomainObjekte zu überwachen, sondern sie auch zu verwalten. Ähnlich, wie es auch bei IMAP gemacht wird, werden die einzelnen DomainObjekte geflaggt, sodass die Mapper Klasse einfach nur die Flags kontrollieren muss. Schau es dir einfach an. Ist eigentlich ein ziemlich simples Pattern. Bei Fragen helfe ich dir gerne.
MfG, Andy
März 3rd, 2009 at 17:55
Ah, immer interessant herauszufinden, dass es etwas schon gab, bevor man es für sich wieder erfindet^^. Auf den ersten Blick sieht mir dieses Pattern meinem Aufbau sehr ähnlich, ich verwende aber statt Flags einfach Arrays die ich in array_diff_*() schmeiße. Auch Factories habe ich beim Erstellen, die mir außerdem die Beziehung Objekt<Unterobjekte<Module zusammensteckt. Mal sehen was noch dazu kommt, auf jeden Fall ist es sehr gut erweiterbar.
März 3rd, 2009 at 20:50
Das Pattern hat mir auch sehr gut gefallen. Es ermöglicht einem die Schnelle Kontrolle ob ein DomainObjekt bereits geladen oder sogar verändert oder gelöscht wurde. So kann man sicher stellen, dass auch wirklich nur dann Objekte geladen werden, wenn sie noch nicht bereits geladen wurden. Zudem ist es natürlich auf diese Weise möglich alle Änderten an DomainObjekten in der Datenbank zu speichern, gelöschte Objekte aus der Datenbank zu löschen und neue Objekte in der Datenbank zu speichern und das alles ohne einen direkten Befehl dafür geben zu müssen. Man implementiert nur eine Methode commit(), die bei ihrem Aufruf über die Arrays der verschiedenen Objekt-zustände iteriert und die entsprechende Aktion ausführt. Wie du wahrscheinlich gerade auch bemerkt hast, rede ich auch von Arrays. Diese habe ich nämlich auch in meiner Implementierung des Unit of Work Patterns verwendet. Jedoch erinnert das kathegorisieren der DomainObjekte in „removed“, „dirty“, „new“ und „loaded“ meiner Meinung nach sehr an das flaggen von Mails beim Internet Message Access Protocol.
MfG, Andy