entity framework - EF5 Code First Fluent EntityTypeConfiguration for tracks & albums models -

i modeling music tracks , albums albums have many tracks , tracks can on 1 album, join table specify it's position in album listing.

here models:

public class track {     public int id { get; set; }     public string name { get; set; }      public int albumtrackid { get; set; }     public virtual albumtrack albumtrack { get; set; } }  public class album {     public int id { get; set; }     public string name { get; set; }      public virtual icollection<albumtrack> albumtracks { get; set; } }  public class albumtrack {     public int albumid { get; set; }     public virtual album album { get; set; }      public int trackid { get; set; }     public virtual track track { get; set; }      public int position { get; set; } } 

and entitytypeconfiguration

public class albumtrackconfiguration : entitytypeconfiguration<albumtrack> {      public albumtrackconfiguration()     {         // albumtrack has composite key         haskey(at => new {at.albumid, at.trackid});          // albumtrack has 1 album, albums have many albumtracks         hasrequired(at => at.album)             .withmany(a => a.albumtracks)             .hasforeignkey(at => at.albumid)             .willcascadeondelete(true);          // albumtrack has 1 track, tracks have 1 albumtrack         hasrequired(at => at.track)             .withrequiredprincipal(t=>t.albumtrack)             .willcascadeondelete(true);     }  } 

the 1 many relationship between albums , albumtracks fine, in addition expected

[albumtrackid] [int] not null, 

code first keeps adding

[albumtrack_albumid] [int] not null, [albumtrack_trackid] [int] not null 

to tracks table.

how can model track album track relationship better properties specify translate in db fields?

[yes, in world track can exist on single album!]

thanks.

making position part of track makes sense suggested.
if you'd still want 'join' table work - , i'd rather disassociate track, albums 'associations', i.e. positions etc...

for work need re-organize relationships bit. ef/cf failing build - because you're asking of isn't natively supported or expected. join, index tables expecting 'multiplicity' on other side.

basically, albumtrack no longer 'join' table - one-on-one track + have album fk albumtrack.

with in mind can following - , that'd create columns, indexes right...

public class track {     public int id { get; set; }     public string name { get; set; }     // public int albumtrackid { get; set; }     public virtual albumtrack albumtrack { get; set; } } public class albumtrack {     public int trackid { get; set; } // <== single primary     public virtual track track { get; set; }      public int albumid { get; set; }     public virtual album album { get; set; }      public int position { get; set; } } public class album {     public int id { get; set; }     public string name { get; set; }     public virtual icollection<albumtrack> albumtracks { get; set; } } 

...and fluent configuration:

modelbuilder.entity<albumtrack>()     .haskey(at => new { at.trackid });     //.haskey(at => new { at.albumid, at.trackid });  modelbuilder.entity<albumtrack>()             .hasrequired(at => at.track)             .withoptional(a => a.albumtrack);             // .withrequiredprincipal(x => x.albumtrack);  modelbuilder.entity<albumtrack>()     .hasrequired(at => at.album)     .withmany(a => a.albumtracks)     .hasforeignkey(at => at.albumid)     .willcascadeondelete(true); 

...and can use like:

var album1 = db.albums.add(new album { name = "track1", });  var tr1 = db.tracks.add(new track { name = "track1", }); var tr2 = db.tracks.add(new track { name = "track2", }); var tr3 = db.tracks.add(new track { name = "track3", }); var tr4 = db.tracks.add(new track { name = "track4", }); var tr5 = db.tracks.add(new track { name = "track5", });  db.albumtracks.add(new albumtrack { track = tr1, album = album1, position = 1 }); db.albumtracks.add(new albumtrack { track = tr2, album = album1, position = 2 }); db.albumtracks.add(new albumtrack { track = tr3, album = album1, position = 3 }); db.albumtracks.add(new albumtrack { track = tr4, album = album1, position = 4 }); db.albumtracks.add(new albumtrack { track = tr5, album = album1, position = 5 });  db.savechanges(); 

(or can 'add' albumtracks, rest go in).

note: don't need composite key more - albumtrack dependent on track alone - i.e. have only 1 record each track - 'an album' attach to.
don't need // public int albumtrackid { get; set; } that's opposite side, fk on albumtrack. , wrong in old setup (as you'd need 'two keys' fk - join table).

and, add, whole structure 'suggests' you're 'splitting' track table - 2 one-to-one tables - , go track/album. has own advantages - while have joins , read/writes (on downside) of flexibility - or e.g. later associate them via normal join table , on.