[Løst] EntityFramework og relasjoner

[HDSoftware]

Folkens. Jeg har følgende struktur i en database (EF6, CodeFirst):

class Document

{

Int ID{get;set;}
string Description{get;set;}

etc.etc.

}

 

class DocFolder

{

int Id{get;set;}

int FolderId{get;set;}

int DocumentId{get;set;}

}

 

class Folder

{

int Id{get;set;}

string Name{get;set;}

}

 

Som dere ser finnes ingen direkte relasjon mellom de forskjellige tabellene. Kun DocFolder har informasjonen som knytter et dokument til en folder. Jeg har prøvd å lage dette til i CodeFirst, men det feiler under kjøring. Har prøvd å legge inn f.eks. [ForeignKey("xxxxx")], men blir liksom ikke helt bra og feiler under kjøring

 

Selv om det tilsynelatende ser ut til at dette er en mange til mange kobling så er det faktisk en kombinasjon. Ett dokument kan kun eksistere i EN folder, men en folder kan selvsagt ha mange dokumenter.

 

Vet at dette med stoooor fordel kunne vært gjort annerledes, men de andre her på bruket har fikset dette på ett vis og bruker det i andre steder. Jeg skal bruke det mot EntityFramework og står fast.

 

Jeg kunne laget NotMapped Properties, men da sitter jeg igjen med masse håndkoding og det vil jeg unngå.

 

Takker for alle tips

[quantum]

du må vel ha fremmednøkkelen i document og ikke docfolder hvis du skal kunne ha flere dokumenter i samme mappe? og hva mener du med "en kombinasjon"? det må vel være en-til-mange eller mange-til-mange, en kombinasjon blir noe sånt som noen-til-mange? det høres snodig ut...

[Enthroner]

La ORMen gjøre jobben for deg!

class Document
{
    int Id{get;set;}
    int FolderId{get;set;}
    string Description{get;set;}
    etc.etc.
}
 
class Folder
{
    int Id{get;set;}
    string Name{get;set;}
    virtual ICollection<Document> Documents {set;get;}
}

[HDSoftware]

Vel, greia er at dette ble laget for lenge siden og jeg skal kode opp noe som må håndtere dette. Det er jo ikek vanskelig å manuellt kode dette her, men hadde håpet EntityFramework hadde greid det automagisk for meg.

 

Forresten, du ser på relasjonene fra feil utgangspunkt. Det er slik:

 

Document 1:1 DocFolder Mange:1 Folder

 

Greia er at det er DocFolder som er limet i relasjonen her. Du kan gjerne se på DocFolder som en record extender da den alltid vil være 1:0 eller 1:1

[HDSoftware]

 

La ORMen gjøre jobben for deg!

class Document
{
    int Id{get;set;}
    int FolderId{get;set;}
    string Description{get;set;}
    etc.etc.
}
 
class Folder
{
    int Id{get;set;}
    string Name{get;set;}
    virtual ICollection<Document> Documents {set;get;}
}

Vel, som du sikkert la merke til så hadde jeg ikke noe FolderId i Document...

[Enthroner]

Så du ikke hadde det, med dette er EF/Code First så hvorfor ikke legge den til og bli med i tiden?

[HDSoftware]

Fordi verden ikke er slik bestandig ;-)

 

Neida.. Greia er at databasen eksisterer ute i tusen hjem og det er ikek opp til meg å endre.

Koden er "Code first", men bare fordi jeg håndkoder selv. I prinsippet er dette eksisterende database med håndkodet model.

[Enthroner]

Da er det strengt tatt Database First men ok.

Da burde du bruke modelBuilder med fluent api https://msdn.microsoft.com/en-us/data/jj591620.aspx

[Vakuum]

Du kan generere klassene basert på databasen.

 

Men som du selv sier så har du en int-kolonne som egentlig er en foregin-key. du har bare glemt å si dette til databasen?. Da kan det eventuelt lønne seg å sette opp dette først. (Enkelt hvis du bruker management studio)

 

Jeg ser forresten ingen mange-mange kobling her. Kunne kanskje vært bedre å ta et skjermbilde fra management studio som viser tabellene?

[HDSoftware]

Nei, det er ingen vits. Dette er bare en visualisering av problemstillingen. Jeg er bare ute etter hvordan man gjør dette ved bruk av annotation. Jeg har løst det manuellt på egen hånd ved å bruke NotMapped og håndkodede Properties, men det er mindre elegant. Grunnlaget for å gi meg rett svar er tilstede i eksempelmodellen. Går det ikke med den modellen så er det en helt annen sak. Problemstillingen er uansett løst på manuellt vis

[HDSoftware]

jeg kjenner så klart til dette med å generere o.s.v. men dette er en modell som ble påbegynnt lenge før det fantes noe T4 templates som gjorde det så det toget går ikke på dette sporet. Orker ikek engang tanken på å gjøre om dette nå.

[Enthroner]

Annotations/Attributes blir borte fra EF7 har MS sagt. Med model builder har du mye bedre kontroll, og det kan testes om du ønsker det.

Jeg ville som sagt brukt det i din situasjon.

[HDSoftware]

Annotations/Attributes blir borte fra EF7 har MS sagt. Med model builder har du mye bedre kontroll, og det kan testes om du ønsker det.

Jeg ville som sagt brukt det i din situasjon.

Borte?? Seriøst? Vil de at alle skal gå over på fluent api da eller? Påkker ta altså. Annotations er jo så enkelt å sette der man vil ha det. Skjønner ikke hvorfor de tar vekk dette :-(

[quantum]

Blir veldig off-topic, men - jeg har litt inntrykk av at dette med bakoverkompabilitet ikke er Microsofts sterke side. Blir det ikke kostbart i lengden?

[Enthroner]

MS støtter alle major releases i minst 10 år.

ASP vNEXT er ikke bakoverkompatibel ettersom det er en helt ny CLR, så at de gjør slike endringer synes jeg er helt innafor.

 

Jeg var ikke helt korrekt i min uttalelse dog - https://github.com/Microsoft/referencesource/tree/master/System.ComponentModel.DataAnnotations/DataAnnotations det vil fortsatt være støtte for Annotations; men det ser ut til at mange av de som tidligere kunne brukes for relations ikke lenger er med.

Som sagt så er nok dette for at POCO (plain old c[#] objects) ikke skal beskrive for tett hvordan de lagres. Eks om du vil bytte datastore fra SQL til en document store eller slik.

 

Det er bedre at denne konfigurasjonen ligger nermere den klassen som har ansvar for faktisk lagring. I tillegg kan du teste modelBuilder uten å bruke reflection, som er et stort pluss