Objekt Designproblem

[darkd0g]

hi alle zusammen,

ich bin dabei meine datenbankstruktur als objekte zu erstellen ... lief alles gut bist ich auf das problem gestoßen bin.

also geplant ist, wenn ein objekt ein child objekt besitzt, dass es das objekt (wenn getObjekt() aufgerufen wird) über die id den datensatz aus der datnebank holt.
---
1.frage: schlechter oder guter ansatz?
---

weiters hab ich jetzt das problem:
design skizze


das problem ist, wenn ich eine instanz von firma habe und ich dann über den mitarbeiter wieder mit getFirma() über den FK vom mitarbeiter die Firma lade, hab ich eine neue Instanz von Firma, obwohl es die gleiche Instanz wie die erste Firma sein sollte.

---
2.frage: wie löst man so eine konstellation am besten?
---

ich hoffe ihr könnt meine problemstellung verstehen.

danke schon im vorraus.
mfg

 

[Cobinja]

Eine Lösung wäre, im Mitarbeiter-Objekt nicht den FK zu speichern, sondern eine Objektreferenz auf die Firma.

 

[7H3 N4C3R]

Zu 1.:
Prinzipiell richtig, wobei das Objekt selbst nicht das andere Objekt aus der Datenbank holt, sondern eine Factory für die Child-Objekte mit dieser ID gefragt wird. IDs sollte man übrigens nie einfach als Zahl betrachten sondern als ein "unbekanntes Wesen". Es ist eben eine ID auf der Datenbank und hat ihre Bedeutung auch nur dort. Und nur dort. Nebenbei kann man gleich dafür sorgen, dass die ID NULL sein kann, wenn man neue Objekte erzeugt und es diese auf der Datenbank nicht gibt. Merkt man sich dann noch seine Kind-Objekte nicht über IDs sondern über Referenzen/Zeiger/whatever, so kann man auch komplexe Datenstrukturen erzeugen, ohne zuerst den Master-Datensatz committen zu müssen.

Zu 2.:
Lässt sich z.B. über eine "Identity Map" lösen. Diese merkt sich, welche Objekte man gerade "draußen" hat. Falls das Objekt bereits lokal vorliegt, gibt es eine Referenz (oder was auch immer in deiner Programmiersprache) darauf zurück und merkt sich dann mit einem Referenzzähler, wie oft auf das Objekt verwiesen wird. Wenn keine Referenzen mehr bestehen, kann man es wieder killen. Wobei es hier viele Spielarten gibt. Wird sich das Objekt nie ändern (irgendwelche Referenzdaten) kann man es auch im Speicher halten, sofern das vertretbar ist. Andererseits muss man auch bedenken, dass man keine Updates auf das Objekt "sieht". D.h. hier sollte man sich schon eine Optimistic- oder Pessimistic-Lock Strategie überlegen, falls das Objekt verändert wird. Außerdem muss man sich die Nebenläufigkeitssteuerung im Programm gut überlegen bei konkurrierenden Updates.

 

[darkd0g]

@7H3 N4C3R

danke erst mal für die ansätze.

ich habs jetzt ca. so wie in deinem 2ten punkt gemacht:

ich habe mir "daten_manager" für jede tabelle, die ich brauche erstellt.
alle abfragen auf daten aus der bestimmten tabelle, laufen über den manager, der speichert die daten und gibt, wenn sie schon einmal geladen wurden die referenz auf das objekt weiter, ansonsten holt er den datensatz aus der DB -> added das objekt zu seinem array und gibt die referenz wieder zurück.

läuft bis jetzt ganz gut und bin bis jetzt noch nicht auf probleme gestoßen

mfg

 

[Darii]

Die Mitarbeiter „Mitarbeiter Collection“ ist so wie sie jetzt ist, etwas overkill, da reicht es völlig, wenn du eine stinknormale Liste verwendest. Kommt aber auch darauf an, was für eine Funktionalität du da drin unterbringen willst, wenn es nur darum geht irgendwelche Mitarbeiter hinzuzufügen und aufzurufen reicht es völlig, wenn du das in der Firma-Klasse unterbringst. Ansonsten schreit das ganze nach einem ORM-System, keine Ahnung, was es da für PHP gibt.