linq - Are there performance implication when using one-to-many bi-directional relationships in Entity Framework? -

we have been implementing our erd in ef.

code first project

public class project {     [key]     [databasegenerated(databasegeneratedoption.identity)]     public int projectid { get; set; }      [index("ix_projectguid", isunique = true)]     [required]     public guid guid { get; set; }      [maxlength(256), index("ix_projectname", isunique = true)]     [required]     public string name { get; set; }      public virtual icollection<userattribute> userattributes { get; set; } } 

code first userattributes

public class userattribute {     [key]     [databasegenerated(databasegeneratedoption.identity)]     public int userattributeid { get; set; }      [index("ix_project_atttribute_name", 1, isunique = true)]     public int projectid { get; set; }     [foreignkey("projectid")]     public virtual project project{ get; set; }      [index("ix_project_atttribute_name", 2, isunique = true)]     public int attributetypeid { get; set; }      [foreignkey("attributetypeid")]     public virtual systemuserattribute systemuserattribute { get; set; }      [maxlength(256), index("ix_project_atttribute_name", 3, isunique = true)]     [required]     public string name { get; set; }      public virtual icollection<userbooleanattribute> userbooleanattributes { get; set; }  } 

so can see last line of each of classes 1-many bidirectional relationship setup.

before introduced 1-many collection of been required todo:

        var jar = context.projects             .where(p=>p.projectid==1)             .join(                 context.userattributes,                 => a.projectid, b => b.projectid,                 (a, b) => new {a, b}); 

now have do:

projects.where(prj=>prj.projectid==1).select(ua=>ua.userattributes).single() 

since lazy-loading in effect, there no degradation performance?

*single -- why need call or similar firstordefault?

looks ok. few quirks it, why assigning both id , guid project. should 1 or other.

single seems out of place because selecting userattributes, 1 or more of them. single implies there one, , if true, design more complex should be.

i assume you'll adding navigation properties string , integer well, fine.

the user*attributes classes should have navigation properties userattributes well.

i've tried analyzing design, , can gives me headache. i'm going assume there outside reason you've chosen pk's have instead of using natural keys. glance, userattributes seems poorly named. it's not user attributes, appears project's attributes (or attributes assignable user each project). ask if breaking attributes 3 separate tables instead of serialzing value string worth headaches, because it's not save space (with exception of integer -- perhaps) , slow down every query need make.