xm22

Im Anschluss an den Beitrag http://www.php.de/software-design/64...raegungen.html (Ein Entity-Typ, mehrere Ausprägungen) stehe ich jetzt vor einem weiteren Problem: Relationen mit Eigenschaften in 1-n- oder n-m-Beziehungen. Wie sollte man die abbilden? Mir sind jetzt 3 Gedanken gekommen, alle mit mehr oder weniger Vor- und Nachteilen: 1. Die Relation als Decorator für das dazugehörige Domainobjekt - Da bräuchte man allerdings immer für die n- bzw. m-Seite einen Decorator extra 2. Vererbung 3. Als generische Attribute im jeweiligen Domainobjekt - Das gefällt mir bisher noch am besten, da man auch noch das Domainobjekt in seiner grundsätzlichen Form erhält. Was sagt ihr dazu? Oder noch einen anderen Weg?

Mister Ad

dr.e.

Hallo xm22,

sofern du das mit generischen Attributen umsetzt, reicht eine einzige Beziehung, die einfach als komplexes Attribut, das eine Liste von Attribute-Objekten beinhaltet. Das Befüllen und übersetzten dieser Beziehung muss ein Mapper entsprechend der Applikation übernehmen.

Die Frage ist bei diesem Konzept nur, ob du die Modellierung der Datenschicht auch in der Anwendung nutzen möchtest, oder gegen diese nochmal abstrahierst. Falls letzteres, dann sieht die Domänen-Objekt-Struktur sicher etwas anderes (=konkreter für die jeweilige Applikation) aus.

Folglich stellt sich die Frage IMHO nur, wenn du die Objekte der Datenhaltung auch in der Applikation nutzen möchtest. In diesem Fall präferiere ich die Lösung mit dem generischen Attribut. Wobei auch hier nochmal bedacht werden sollte, wie die Klassen-Struktur der konkreten Applikation aussieht. Oft ist es auch garnicht notwendig in einer zentral verwendeten Komponente generische Abhängigkeiten zu den verwendenen Komponenten aufzubauen, weil der Benutzer beispielsweise am Gästebuch-Eintrag hängt und nicht umgekehrt. So brauchst du dein Usermanagement nicht anzupassen, sondern einfach in deiner Gästebuch-Applikation ein konkretes Attribut für die Beziehung von Eintrag zu Benutzer zu verfassen und das Problem ist erledigt. Mal am besten mal ein komplettes UML, dann lässt sich da leichter diskutieren.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Nein, die Attribute sind fix. Aber so machen könnte man das ja trotzdem.

Vielleicht verstehe ich das falsch, aber eigentlich will ich die Attribute im selben Kontext auch in der Applikation nutzen.


Zum Verständnis: Es geht um eine Relation von Nachricht <- empfänger -> Benutzer

Die Relation empfänger soll u. a. noch das Attribut Status (Im Sinne von gelesen/ungelesen) beinhalten.

dr.e.

Hallo xm22,

Die Attribute sind Teil der Applikation und sollten eben nicht allgemein am Benutzer hängen, sondern zu diesem nur assoziiert sein. So kannst du die Einstellungen unter deiner Applikation speichern und das Thema Usermanagement ist weiter generisch abbildbar. Andernfalls müsstest du sonst dein UMGT für jede Applikation neu schreiben.

Eine Relation sollte nicht allzuviele Informationen tragen, sie soll lediglich "charakterisieren". Für deine konkrete Aufgabenstellung bietet es sich daher an, mehrere Status-Instanzen zu haben (gelesen, ungelesen, ...), die mit der Nachricht assoziiert sind. Eine weitere Assoziation geht dann von Nachricht zum Benutzer und von der Nachricht über eine weitere Beziehung zum Empfänger. So kannst du eine Nachricht im System eindeutig speichern.

Vielleicht gibt dir der Thread Nachrichten-System im APF-Forum noch eine weitere Idee für die Umsetzung.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Sind sie doch... Dadurch, dass sie nur die Relation Message <-> Benutzer betreffen, ist der Benutzer selbst nicht darauf angewiesen.

Du meinst, die eigentliche Relation enthält nur die Relation, während die dazugehörigen Informationen nochmal separat abgelegt werden?


Es geht mir primär auch nicht um das Ablegen in der DB, sondern um die Einbindung der Relationseigenschaften in der Applikation

Den Thread lese ich jetzt.


EDIT: Mal sehen, ob ich das so verstanden habe, wie es gemeint ist. Der relevante Teil, den ich da jetzt extrahiert habe, ist also folgender:

Es gibt

Message (subject|text)

MessageToSender(Message|User)

Folder (User|Name)

MessageToFolder (Folder|Message)

MessageInfo (MessageToFolder|Key|Value)

Richtig?


EDIT: Btw - Jetzt habe ich bei deinem ORM den Zusammenhang zwischen Relations-Config und loadRelatedElements verstanden

KarlEgon

Ich habe versucht ein Nachrichtensystem zu entwickeln, bei dem man nicht die Nachricht ansich doppelt abspeichern muss.
Dadurch, dass die Nachricht verschiedende Makierungen (gelesen, ungelesen, archiviert, versendet und was weiß ich noch alles) haben kann und das sowohl beim Sender als auch beim Empfänger, habe ich die MessageInfo eingeführt. Hier wird alles abgespeichert was nur eine Person betrifft (oder einen Ordner der einer Person gehört) Die Nachricht ansich bleibt dann einmalig im System. Somit sind auch mehrere Empfänger kein Problem. Sollte ein Benutzer die Nachricht löschen, dann wird einfach die MessageInfo gelöscht, sozusagen die Verbindung zwischen Ordner und Nachricht, dadurch sieht der Benutzer die Nachricht nicht mehr, auch wenn sie vielleicht im Hintergrund noch vorhanden ist, da ein anderer Benutzer die Nachricht noch nicht gelöscht hat.

Ich würde folgendes vorschlagen:
Message (Subject|Text)
MessageInfo (MessageID|FolderID|Name|Status)
Folder (UserID|Name)
User(...)

Es gibt kein wirkliches MessageToSender oder MessageToReceiver, da dies alles über das MessageInfo Object geregelt wird. Dort habe ich dann als Name "Sender" oder "Receiver" abgefragt und konnte so die Nachrichten wunderbar zuordnen.

xm22

So in etwa hatte ich mir das auch gedacht.. Mir gefällt auch, dass alles im Prinzip über Folder und nicht über den Benutzer geregelt wird. Das ist es wahrscheinlich, was Dr.E. vorhin meinte..

dr.e.

Jep, darauf wollte ich hinaus ("Kategorisierung").

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Hier fällt mir nur auf: Wie soll der Absender abgebildet werden?

Was mir einfällt (Pseudo-Pseudo-Code):
Allerdings wäre das ja dann auch redundant. In dem verlinkten Bsp. wird beim Senden der Nachricht folgendes ausgeführt:
Bedeutet das hier, dass einfach quasi ein Dummy-Datensatz gesetzt wird, anhand dessen man den Sender auslesen kann?

KarlEgon

Diese Infos stehen in MessageInfo.
Der Empfänger schaut in seinen Ordner, von dort geht es über die MessageInfo zur Nachricht. Sobald ich die Nachricht habe, kann ich die MessageInfo abfragen welche zur Nachricht und dem Sender gehört und bekomme dadurch auch den User raus.
Kann man sicherlich auch über eine extra Beziehung lösen, aber die muss man dann auch wieder pflegen, obwohl die Informationen im Grunde schon vorhanden sind.
Ich merke gerade, dass das Prinzip in diese Richtung noch gar nicht zuende gedacht ist. Daran muss ich wohl noch arbeiten Sobald der Sender die Nachricht löscht, können die Empfänger nicht mehr sehen vom wem die Nachricht kam. Müsste mich erst nochmal genauer in den Quellcode einarbeiten um zu schauen ob ich nicht doch schon daran gedacht habe.

Edit:
Genau das wird im Grunde genommen gemacht