virtual DbSet<> in the current EF Core (7 or 8)

Question

EDIT: This question has been closed because someone thought it is a duplicate for another question on SO. It is not. The duplicate question, and all of the (old) docs I've found, deal with adding virtual to entity class navigation properties to enable lazy loading. This question is about what happens if I add virtual to the DbContext DbSet<> property.

We now return you to the original post:

I'm looking for definitive guidance about the effect of adding virtual to my existing DbSet DbContext properties in EF Core 7 or 8.

This came about because I want to use the Moq.EntityFrameworkCore NuGet package to mock my DbContext, which requires my DbSet<TableName> statements to be virtual.

---

EDIT: The above statement is the intended, complete question. The following is the original version of the question, which includes my observation that the virtual keyword in question has something to do with "lazy loading". I now know that is incorrect, and I understand that my question (above) implies an additional question: Why can my DbSet and my entity classes have virtual navigation properties and DbSet properties? Where is the concrete implementation of these virtual properties? The answer explains that very nicely.

I am using EF Core 8. Earlier versions of EF Core provided lazy loading features related to decorating the DbSet<TableName> statements in the DbContext class with the virtual keyword, for example:

public virtual DbSet<PatientTestEntity> PatientTestEntities { get; set; }

The current documentation makes no mention of this (as far as I can tell).

I'm looking for definitive guidance about the effect of adding virtual to my existing DbSet DbContext properties in EF Core 7 or 8.

This all came about because I want to use the Moq.EntityFrameworkCore NuGet package to mock my DbContext, which requires my DbSet<TableName> statements to be virtual.

Answer 1

The answer to the OP is: Adding virtual to the DbSet<> property in the DbContext has no effect. See below for an explanation of how EF creates proxies from the original DbContext and entity classes.

I think, if a library needs (such as EF or some Moq test libraries) to generate a proxy class at runtime to achieve its purpose, it's a good practise to sign all complex type properties as virtual to enable extending actual class.

Let's illustrate this through the Lazy loading feature of the Entity framework;

Ef needs to virtual keyword on the navigation properties to enable lazy loading mechanism. (also "LazyLoadingEnabled" property of the configuration must be enabled)

For Lazy Loading purpose, Entity Framework needs a hook, i.e. 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. Unfortunately Entity Framework is unable to alter the POCO entity classes because it's your code, but what it can do is deriving from your class and overriding the property to inject it's magic.

To do so, EF uses proxy class generation mechanism. Which means, it creates what is called a proxy, i.e. it creates a class at runtime which derives from your POCO class, like:

public class EntityTypeProxy : EntityType
{
    public override ICollection<AnotherEntity> AnotherEntities
    {
        get { /* Load child data here */ }
        set { /* ... */ }
    }
}

So what you get when you retrieve the entities 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.