Take the 2-minute tour ×

It seems that lazy loading does not work the same with code-first as it does with db-first:


public class Project
    public long ProjectId { get; set; }

    public virtual string Name { get; set; }


public class TestCase
    public long TestCaseId { get; set; }

    public virtual Project Project { get; set; }
    public virtual long ProjectId { get; set; }

In this DbContext:

public class TestDbContext : DbContext
    public TestDbContext() : base("TestIckle") 

    public DbSet<Project> Projects { get; set; }
    public DbSet<TestCase> TestCases { get; set; }

When I try to to this in my code it does not work:

    Console.WriteLine(_db.Configuration.LazyLoadingEnabled); //prints true
TestDbContext _db = new TestDbContext();
var testcase = _db.TestCases.Create();
testcase.Project = _db.Projects.Find(7);

//the following line outputs 0 with Code-First
//the following line outputs 7 with DB-First

Is a code-first model less capable than a db-first one? Seems odd that I would have assign the nav property and the pkey for it, which makes me think I have something configured wrong.

Should the following ever work?

var x = _db.TestCases.Create();
x.ProjectId = 7;
Console.WriteLine(x.Project.Name); //this never seems to work

Would be nice, seing as x knows which context it is attached too, I would have thought it could have handled this situation.


share|improve this question
Can you please clean up your fourth example? I'm not sure where how you would be getting 0 or 7 from testcase.Project. –  IronMan84 Mar 19 '13 at 14:56
add comment

1 Answer

up vote 0 down vote accepted

In those last two examples, Entity Framework is not loading up those entities because you have not committed those relationships to the database. It won't automatically populate the FK ID when you've assigned the navigation property, nor will it populate the navigation property when all you've done is set the ID.

Entity Framework is smart enough, though, to know that when you assign to either of those properties (i.e. the ID or the navigation property) that it will populate the correct values in the future for both properties. But before you do any actual commit it will not know to automatically populate that value. Nor should they, if you think about it: What would happen if there's a drop down on a page that maps to one of those properties? Every single time a user clicks on it there would have to be a database call to correctly keep the mapping. That could translate to a much slower, much more breakable application.

share|improve this answer
I agree with you on the last example. Further reading shows that docs for _db.TestCase.Create() explicitly state that this object is not attached to the context... which seems pointless, I might as well just do a new TestCase(). BUT, it seems odd that listing #4 has a different result depending on whether you have Code First or DB First. But I think you ultimately answered my question, this is expected behaviour. Just going to sit for a bit before I mark as asnswered. Thanks. –  sheamus Mar 19 '13 at 15:32
Actually relation is updated when you are adding entity to context, not when you are committing it to database stackoverflow.com/a/15221140/470005 (see UPDATE part) –  Sergey Berezovskiy Mar 19 '13 at 15:34
@lazyberezovsky, I stand corrected. Thanks! –  IronMan84 Mar 19 '13 at 15:42
add comment

Your Answer


