EntityFramework und Jointable

Hallo zusammen

Wie greife ich denn beim Entityframework auf eine Jointable einer n zu m Beziehung zu.

Beispiel:
Es gibt eine Tabelle Student und eine Tabelle Studienfach.
Typische n:m Beziehung

In der Datenbank gibt es nun Student, Studienfach und die JoinTable StudentStudienfach.

In meinem EF kann ich nun aber nur auf Student oder Studienfach zugreifen. Die Jointabelle gibt es nicht.

Kann mir jemand helfen.

Niemand der mir helfen kann?

Dravere

Wieso brauchst du sie denn? Eine typische N:M Relation versteckt das Entity Framework, da du darauf gar nicht zugreifen musst.

Wenn du sie sichtbar haben willst, musst du diese Relation selber im Designer erstellen, in dem du eine weitere Entity erstellst und von dieser aus jeweils eine 1:N Relation zu den beiden anderen Entities aufbaust.

Grüssli

asc

Da es vielleicht Unterschiede macht: Wie setzt du das Entity Framework ein (Model First, Database First, Code First...)?

Ich habe mich bislang im wesentlichen mit "Code First" beschäftigt, und danach würde ich sagen: Direkt gar nicht, es sei den du erstellt auch eine Klasse für diese Jointable. Normalerweise braucht man den direkten Zugriff auch nicht, da man üblicherweise (in deinen Fall) entweder vom Studenten kommend die Studienfächer erreichen will, oder umgekehrt. Und diese sollten wenn man gegenseitig navigieren können soll, auch in beiden Klassen als Collection auf die jeweils andere enthalten sein.

// Auszug beim Ansatz Code First

class Student
{
  //...
  public virtual ICollection<Studienfach> Studienfaecher {get; set;}
}

class Studienfach
{
  //...
  public virtual ICollection<Student> Studenten {get; set;}
}

Wenn man wirklich den Zugriff auf die Jointable benötigt (oder wie bei uns die Jointable noch Zusatzinformationen enthält, z.B. was für eine Art von Verbindung es ist), muss man bei Code First eine weitere Klasse einführen, und die Verknüpfungen anpassen.

// Auszug beim Ansatz Code First mit Jointable als Klasse

class Student
{
  public int Id { get; set; }
  public virtual ICollection<StudienfachStudent> StudienfachStudenten {get; set;}
  //...
}

class StudienfachStudent
{
  public int StudentId;
  public int StudienfachId;
  public virtual Student Student {get; set;}
  public virtual Studienfach Studienfach {get; set;}
}

class Studienfach
{
  public int Id { get; set; }
  public virtual ICollection<StudienfachStudent> StudienfachStudenten {get; set;}
  //...
}

Imho sind die O'Reilly-Bücher hierzu ganz gut ("Programming Entity Framework" [Bezieht sich auf EF 4.0]; sowie der Ergänzungsband "Programming Entity Framework: Code First" [Ergänzungen um Code First basierend auf EF 4.1]; Demnächst kommt noch "Programming Entity Framework: DbContext" heraus).

Ok. Nun habe ich mal wieder was neues gehört.

Model First, Database First, Code First...

Wenn ich das richtig verstehe, bezeichnet diese verschiedenen Arten einfach das was ich zuerst erstellt habe.

Das andere habe ich auch verstanden. Und bin zur Erkenntnis gekommen dass ich gar keinen direkten Zugang zur Jointabelle brauche.

Aber was ich nicht verstanden habe ist der Bezug der beiden Dinge zueinander.

Ändert sich der Zugriff auf die Jointabelle abhängig von Code First bzw Model First oder Database First?

asc

y-vonne schrieb:

Wenn ich das richtig verstehe, bezeichnet diese verschiedenen Arten einfach das was ich zuerst erstellt habe.

Jein. Prinzipiell liegt dabei durchaus das zugrunde, womit man anfängt (wobei dies nicht zwingend ist, es gibt durchaus Unterstützung um beispielsweise aus einer vorhandenen Datenbank z.B. Klassen im Stile von Code First zu generieren), wirkt sich aber auch auf anderen Stellen aus.

Code First ist erst mit dem Entity Framework 4.1 eingeführt wurden, und dürfte vom Codestil her am Leichtgewichtigsten erscheinen. Dennoch hat jeder dieser Techniken seine eigenen Vor- und Nachteile-

y-vonne schrieb:

Ändert sich der Zugriff auf die Jointabelle abhängig von Code First bzw Model First oder Database First?

Code First hat von der Codeseite her nicht direkt mit den andern beiden zu tun, z.B. wird bei Code First alles im Code definiert, die anderen Techniken arbeiten mit speziellen Metadateien.

Es gibt im Internet einige Gegenüberstellungen wie z.B.: Entity Framework 4.1 - Code-/Model First und die Unterschiede einer Gemeinsamkeit oder Code First vs Model/Database-First.

Dank dir mal für deine ausführliche Antwort.

Da ich aber zwingend auf das .Net Framework 3.5 festgelegt bin kann ich Codefirst nicht nutzen.

Habe nun auch mal mit dem Modellieren der Klassen begonnen und daraus dann den Code und die Datenbank generiert.

Nun bin ich aber bisher so vorgegangen, dass ich selber nochmals Klassen definiert - meine Models für mein MVVM - die ich dann wiederum auf die Objekte vom EF gemappt habe.

Mit neu gewonnenen Kentnissen frage ich mich aber ob es nicht eher sinnvoll ist die Objekte vom EF direkt als Model für das MVVM zu verwenden. Was meint ihr?

Habt ihr hier dazu keine Lösung?

asc

y-vonne schrieb:

Mit neu gewonnenen Kentnissen frage ich mich aber ob es nicht eher sinnvoll ist die Objekte vom EF direkt als Model für das MVVM zu verwenden. Was meint ihr?

Prinzipiell ist dies möglich, ja nach gewählten Design und Anforderungen. Eine direkte Antwort wirst du daher wohl kaum erhalten.

Ich würde es von mehreren Faktoren abhängig machen:

a) Wieviele Abhängigkeiten verschafft man sich.

Beispielsweise wären bei CodeFirst die Abhängigkeiten sehr gering, da die Klassen in diesem Ansatz sehr eigenständig sind, und eigentlich keinerlei Abhängigkeiten besitzen; nei den andern beiden Ansätzen können, soviel ich weiß, die Abhängigkeiten wesentlich größer sein [Über Vererbung etc.].

b) Welche Form von Schichtentrennung ist ggf. zu berücksichtigen (z.B. gleichzeitige Unterstützung von ASP.Net und WPF-Clients...)? Wie sehr bindet man sich damit an die Datenzugriffsschicht?