Design - Rückwärtsbeziehungen
-
Hi!
Ich stehe gerade vor einer Design-Frage (bzw will ich jemanden diesbezüglich beraten) und wollte euch mal fragen, wie ihr das so handhabt
Es geht um Rückwärtsbeziehungen zwischen Objekten. Um mal ein Praxis-Beispiel zu nennen: In einer Schulklasse sitzen Schüler. Wenn man die Objekte "Schüler" und "Kurs" betrachtet, hat jeder Schüler x Kurse und in jedem Kurs sitzen x Schüler.
Nun gibt es (mindestens) zwei Möglichkeiten:- Rückwärtsbeziehung: Das Objekt Schüler hat einen Verweis auf alle besuchten Kurse. Jeder Kurs hat einen Verweis auf jeden ihn besuchenden Schüler.
- Einseitige Beziehung: Das Objekt Schüler kennt niemanden, hat also nur Name, Vorname und evtl Tutor/Klassenlehrer. Das Objekt Kurs hat dafür einen Verweis auf alle seine Schüler.
Oder andersrum, die Schüler kennen ihre Kurse, die Kurse aber ihre Schüler nicht - ersteres scheint mir aber in diesem Beispiel geeigneter.
Nun steht für mich die Frage: Welches Modell? Die Verweise bleiben konstant, d.h. die Schüler bleiben in ihren Kursen.
Ich persönlich habe immer bevorzugt, Rückwärts-Beziehungen zu vermeiden und möglichst viele Klassen "alleinstehend" zu haben. Beim implementieren der Rückwärts-Beziehungen würde aber hier kein wirklicher Nachteil entstehen, da die Beziehungen ja konstant bleiben.
Wie macht ihr das? Was ratet ihr mir? Oder hängt das (wie immer) vom Anwendungsfall ab?Dank und Grüße,
Badestrand (<- da wär ich jetzt übrigens gern
)/e: Hatte mich im Threadtitel verschrieben
/e2: Diese beiden Edits eingefügt
-
Es hat beides seine Vor- und Nachteile - da hängt es von der konkreten Anwendung ab, was du verwenden willst (die Zeugnisse zu schreiben geht z.B. einfacher, wenn du auch Rückwärtsbeziehungen eingebaut hast).
-
In einer Datenbank würd man wahrscheinlich eine klassische m:n Tabelle in Betracht ziehen.
Es sei den jeder Schüler könnte nur in einem Kurs bzw. bekäme Einzeluntericht.Ich teile die Sichtweise, das zumindest ein Kurs seine Schüler kennen sollte.
Somit könnte der Tutor dann eine Liste von Noten an seine Schüler verteilen z.b. als Use Case.Für Schüler ist die Frage, ob es einen Use Case wie "Drucke Stundenplan" gibt.
Ohne diese Anwendungsspezifische Sichtweise kann man imho keine konkrete Lösung finden.
Implementierbar sind alle 3 von dir genannten Varianten.
-
Ich persönlich würde mich einfach an das Publisher / Subscriber pattern halten.
Schüler kann sich bei X Kursen anmelden/abmelden(auch wenn das nicht benötigt wird).
Umgekehrt bietet der Kurs den Schülern eine An- und Abmeldemöglichkeit an.
Auch wenn du sagst es bleibt statisch so kannst du dieses Muster trotzdem nutzen und hast solltest du trotzdem mal Flexibilität haben wollen alle Türen offen.
-
Cool, ihr habt mir sehr geholfen, danke euch!
Ich weiß zwar immer noch nicht, was ich nun nehme, gucke mir aber deshalb erstmal den konkreten Anwendungsfall an
-
würd mir auch angucken, wie damit gearbeitet werden soll. was ist ein kurs? ist das etwas fixes, ist es flexibel? muss buchhaltung über vergangene kurse und deren teilnehmer geführt werden, möglicherweise über vortragendenwechsel während des laufenden kurses? wenn man das alles weiss, kann man sich gedanken über ein konzept machen.