ids oder nested objectx
Hallo,
ich hab da noch mal eine Designfrage:
Gibt es eine Entscheidungshilfe, in welchem Fall man in einem Datenobjekt Nested Objects und wann man referenzen zwischen den Objekten speichert.
Ich habe z.B. Eine Klasse Projekt, die Projekte sind immer einem Kunden zugeordnet.
Gehört in die Klasse Projekt eine Referenz auf Kunde oder bekommt die Klasse eine Eigenschaft mit dem Kunden?
Ich möchte in diesem Projekt zum ersten mal NHibernate benutzen, was ist da einfacher zu realisieren ?
Gruß Dominik
Hallo d.gierse,
ich verstehe nicht ganz, worauf du hinaus willst und was du unter "Nested Objects" verstehst. Da Variablen von Referenztypen immer Referenzen enthalten, gibt es da eigentlich keine Wahlmöglichkeit. Entweder du hast eine Referenz oder du hast keine. Aber du kannst nicht sagen, dieses Objekt soll direkt enthalten sein oder nur referenziert werden.
Ich verstehe auch nicht den Unterschied zwischen Referenz und Eigenschaft. Typischerweise würde ja eine Eigenschaft eine Referenz liefern, die einer Membervariable des Objekt gespeichert ist. Wenn man eine Eigenschaft hat, hat man also auch die Referenz und andersherum wird es meistens auch zutreffen.
herbivore
OK,
dann war das schlecht beschrieben. Hier mal ein Beispiel. Ich habe z.B. 2 Klassen A und B.
Klasse A ist in beiden Fällen gleich:
public class Kunde
{
public int ID {get; set;}
public string Name {get; set; }
.
.
.
}
Bei einem Nested Object (wie wir das immer nennen) ist die Property ein Typ der Klasse, auf die verwiesen wird. Z.B.:
public class Projekt
{
public Kunde ProjektKunde { get; set; }
public DateTime Projektstart { get; set; }
.
.
.
}
Wenn ich mit einer Referenz auf den Kunden arbeiten würde hätte ich z.B. sowas:
public class Projekt
{
public int KundeID { get; set; }
public DateTime Projektstart { get; set; }
.
.
.
}
Bei dem ersten Ansatz hab ich ein Member vom Typ Kunde, der auf das Kunde-Objekt referenziert, beim zweiten hab ich eine ID, über die ich an den Kunden kommen kann.
Ich kenne da nur keine Entscheidungshilfe, wann man welchen der beiden Wege nimmt. Außerdem möchte ich mal NHibernate nutzen und weiss noch nicht was da einfacher zu realisieren ist.
Hallo d.gierse,
zu NHibernate kann ich nichts sagen, aber deine eigentliche Frage würde ich klar mit public Kunde ProjektKunde { get; set; } beantworten.
herbivore
Ich würd sagen das gehört jeweils in eine andere Schicht.
Die Version mit der Id in die Datenschicht und die mit den Referenzen in die Businessschicht.
loop:
btst #6,$bfe001
bne.s loop
rts
gut, aber bekomm ich dann nicht Zirkelbeziehungen, wenn dann ein Projekt einen Kunden enthält und ein Kunde wiederum eine Liste seiner Projekte hat ?
Es ist eher die Frage ob das ein Problem ist, wenn du die Zirkelbeziehung hast.
Wenn du die Datenbank als ObjektModell abbilden willst, ist es ja richtig.
Wenn du es aber XmlSerialisieren willst, bekommst du ein Problem, dann solltest du dir ein Objektmodell einfallen lassen, bei dem es keine Zirkelbeziehungen gibt. Dieses stellt für mich dann eine höhere Schicht dar.
loop:
btst #6,$bfe001
bne.s loop
rts
Hallo d.gierse,
ob zirkuläre Beziehungen schlecht oder ok sind, hängt davon ab, wie eng die Klassen zusammengehören.
Wenn du eine Person x verschiedenen anderen Objektarten zuordnen kannst (Projekten, Verträgen, Rechnungen, Abteilungen, Berechtigungsgruppen, usw.) dann wäre es ungünstig, wenn du überall zirkuläre Beziehungen hättest. Dann sollte die Person am besten gar nichts über diese Beziehungen wissen, weder über eine Referenz noch über eine Id, weil dann die Personen-Klasse trotzdem jedesmal erweitert werden müsste, wenn eine neue Beziehung dazu kommt. Besser ist es in dem Fall, in den anderen Klassen (Projekt, Vertrag, ...) eine statische Methode zu implementieren, mit der mal alle Objekte dieser Klasse zu einer bestimmten Person "heraussuchen" kann. Dabei kann und sollte die "Suche" durchaus besser implementiert sein, als dass man alle Objekte der Klasse durchgeht und schaut, ob sie die Person enthalten. Man könnte z.B. ein Dictionary <Person, List<Projekt>> verwenden, das in der Methode für das Hinzufügen/Entfernen einer Person zu/aus einem Projekt aktualisiert wird.
herbivore