2009-04-27 20 views
0

Kann mir jemand helfen zu verstehen, wie man eine Kompositionsbeziehung am besten modelliert?Wie modellierst du eine einfache Kompositionsbeziehung?

Wenn ich zum Beispiel einen Schüler habe die viele Zeitplan haben kann, würde ich schaffen grob:

class Student 
{ 
    prop long Pk { get; set; } 
    prop string Name { get; set; } 
    prop List<Schedule> Schedules { get; set; } 
} 

class Schedule 
{ 
    prop string Semester { get; set; } 
    prop List<Course> Courses{ get; set; } 
} 

Irgendwo auf die ganzen Linie ich ein Schedule Objekt haben kann, und will feststellen, welche Schüler es gehört . Ich möchte Schedule.Student.Name schreiben können und den Namen des Schülers erhalten. Füge ich meinem Schedule-Objekt auch eine Student-Eigenschaft hinzu?

Meine Anwendung hat einen Student Pk an mein Schedule-Objekt übergeben, um CRUD-Funktionalität zu machen. Ich behalte den Student PK als private Variable, um ihn im Griff zu behalten, wenn ich ihn brauche.

Da meine Anwendung komplexer wird, fällt es mir schwer, das aufrechtzuerhalten, was ich gemacht habe. Was sind deine Vorschläge für mich? Was kann ich sonst noch beachten (Bücher/Links), um diese Grundlagen zu verbessern und besser zu verstehen?

Antwort

2

"Ich möchte in der Lage sein, Schedule.Student.Name zu schreiben und den Namen des Schülers als Gegenleistung zu erhalten. Füge ich meinem Schedule-Objekt auch eine Student-Eigenschaft hinzu?" Ja.

Was Sie beschreiben (Unterstützung von Fremdschlüsseln für Nachschlage- und Objektreferenzen zur einfachen Navigation des Objektdiagramms) klingt wie eine wirklich gute Übereinstimmung für einen objektrelationalen Mapper (ORM). Ein gutes ORM lädt automatisch das zugehörige Objekt/Objekte mit dem FK/PK (wenn der Schedule beispielsweise ein StudentPK-Feld hat, wird der Mapper das Laden/Mapping der Student-Eigenschaft für Sie übernehmen). Es gibt viele Produkte dieses Typs: Sie können integrierte .NET-Frameworks wie die Entity Framework, Open-Source-Produkte wie NHibernate oder kommerzielle Produkte wie LightSpeed, LLBLGen, EntitySpaces oder OpenAccess (Offenlegung: Ich arbeite für eine Firma, die macht eine kommerzielle ORM). Google für ORM oder objektrelationale Mapper, oder check Wikipedia, für einen Überblick über die Art von Dingen, die ich beschreibe.

+0

Aber wenn ich hinzufügen, einen Student eigenschaft auf mein Schedule Eigentum, was mich zu tun, dies zu stoppen: Student.Schedules [0] .Student.Schedules [1] .Student.Schedules [0] .Student.Schedules [0 ].Name. Ist das nicht eine zirkuläre Referenz? Ist das erlaubt? –

+0

Ja, das ist erlaubt. Es verursacht keinen unendlichen Rückschritt, weil (a) wenn Sie die Objekte von Hand erstellen, Sie bereits vorhandene Objekte wiederverwenden (wenn Sie beispielsweise einen Zeitplan erstellen, legen Sie seine Student-Eigenschaft auf den vorhandenen Student fest, nicht auf Erstellen Sie einen neuen Student) oder (b) wenn Sie ein ORM verwenden, wird festgestellt, dass ein Schlüssel auf ein vorhandenes Objekt verweist und es wiederverwenden kann. Auch die meisten ORMs werden standardmäßig faul laden: z.B. Wenn Sie einen Student erstellen, füllen sie die Schedules-Auflistung auf, wenn Sie danach fragen (und füllen Sie stattdessen nur Schedule.Student aus, wenn Sie danach fragen). – itowlson