实体框架：为什么使用虚拟关键字在DbContext中声明属性

Question

i rare use EF. so i have a question. if we do not use virtual keyword with dbset then lazy load will not work?

i read a article from this link https://stackoverflow.com/a/24114284/5314244 they provide code like

public class AppContext : DbContext
{
    public AppContext()
    {
        Configuration.LazyLoadingEnabled = true;
    }

    public virtual DbSet<AccountType> AccountTypes { get; set; }
}

public class AccountType
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<AccountCode> AccountCodes { get; set; }
}

public class AccountCode
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public Guid AccountTypeId { get; set; }
    public virtual AccountType AccountType { get; set; }
}

they said :

The virtual keyword on the navigation properties are used to enable lazy loading mechanism, but the LazyLoadingEnabled property of the configuration must be enabled.

The virtual keyword on AccountType::AccountCodes navigation property will load all account codes the moment there is a programmatically access to that property while the db context are still alive

if we declare this code without virtual keyword public DbSet<AccountType> AccountTypes { get; set; } public DbSet<AccountType> AccountTypes { get; set; } public DbSet<AccountType> AccountTypes { get; set; } then when this line execute var accountCodes = accountType.AccountCodes; what will happen?

Error will thrown or null will be stored in accountCodes variable?

second question what is default in EF---> lazy load or eager loading? how many type of loading option available ?

thanks

Answer 1

The approach you want to achieve, lazy loading, means that the data provider, in your case Entity Framework, retrieves certain data at the time you need it. If, for example, you access all account types you probably don't need to access all account codes for these account types thus retrieving them from the database would be unnecessary.

If you had to write the SQL yourself, you would most likely write a plain select statement without joining the child relations:

SELECT * FROM AccountTypes;

Another use-case on the other hand might need access to this data so you would either end up with eagerly loading it which results in a join operation...

SELECT * FROM AccountTypes JOIN AccountCodes ON AccountCodes.AccountTypeId = AccountTypes.Id;

...or to rely on Entity Framework's lazy loading ability.

The latter case requires Entity Framework to do the following: First, selecting all account types and then, at the time your user-code accesses the account codes, emitting another select statement to retrieve the codes for the respective account type. To do so, Entity Framework needs a hook, ie it must know when you access the navigation property, which is in general impossible because this would need additional code in the getter of this property:

public class AccountType
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<AccountCode> AccountCodes
    { 
        get { /* Load child data here */ }
        set { /* ... */ }
    }
}

Unfortunately Entity Framework is unable to alter the POCO class because it's your user-code , but what it can do is deriving from your class and overriding the property to inject it's magic. For this to work it creates what is called a proxy , ie it creates a class at runtime which derives from your POCO class, like:

public class AccountTypeProxy : AccountType
{
    public override ICollection<AccountCode> AccountCodes
    { 
        get { /* Load child data here */ }
        set { /* ... */ }
    }
}

So what you get when you retrieve the account types is actually a bunch of proxy instances, which you can confirm during debugging.

If you would not add the virtual keyword to the navigation property or if you sealed the class, Entity Framework could not override the property or could not derive from the class at all and thus lazy loading would not work.