Navigation Property Should Be Virtual - Not Required in Ef Core

navigation property should be virtual - not required in ef core?

virtual was never required in EF. It was needed only if you want lazy loading support.

Since Lazy loading is not yet supported by EF Core, currently virtual have no special meaning. It would when (and if) they add lazy loading support (there is a plan for doing so).

Update: Starting with EF Core 2.1, Lazy loading is now supported. But if you don't add Microsoft.EntityFrameworkCore.Proxies package and enable it via UseLazyLoadingProxies, the original answer still applies.

However if you do so, the thing's totally changed due to the lack of the opt-in control in the initial implementation - it requires all your navigation properties to be virtual. Which makes no sense to me, you'd better not use that until it gets fixed. If you really need lazy loading, use the alternative Lazy loading without proxies approach, in which case again virtual doesn't matter.

Why Navigation Properties are virtual by default in EF

If you define your navigation property virtual, Entity Framework will at runtime create a new class (dynamic proxy) derived from your class and uses it instead of your original class. This new dynamically created class contains logic to load the navigation property when accessed for the first time. This is referred to as "lazy loading". It enables Entity Framework to avoid loading an entire tree of dependent objects which are not needed from the database.

In some circumstances, it is best to use "Eager Loading" instead, especially if you know that you will be interacting with related objects at some point.

Julie Lerman really is the authority on all things Entity Framework, and she explains this process very well in her MSDN Article Demystifying Entity Framework Strategies: Loading Related Data

Eager loading with Include is useful for scenarios where you know in advance that you want the related data for all of the core data being queried. But remember the two potential downsides. If you have too many Includes or navigation paths, the Entity Framework may generate a poorly performing query. And you should be careful about returning more related data than necessary thanks to the ease of coding with Include.

Lazy loading very conveniently retrieves related data behind the scenes for you in response to code that simply makes mention of that related data. It, too, makes coding simpler, but you should be conscientious about how much interaction it’s causing with the database. You may cause 40 trips to the database when only one or two were necessary.

If you are developing a Web Application where every communication with the server is a new context anyway, Lazy Loading will just create unnecessary overhead to maintain the dynamic class for related objects that will never be loaded. Many people will disable lazy loading in these scenarios. Ultimately, it's still best to evaluate your SQL queries which EF has built and determine which options will perform best for the scenario you are developing under.

Using Virtual on navigation properties

You use virtual properties on entities, so Entity Framework can create a proxy class at runtime that inherits from your entity and injects a stub into overridden properties. This stub does a database call when you access the property's getter from code.

Entity Framework Core does not support lazy loading (yet, and probably never will), so there's no reason for it to mark properties as virtual.

See also: Loading Related Data - Entity Framework Core 1.0.0 Documentation in the officical documentation, Lazy Loading · Issue #3797 · aspnet/EntityFramework · GitHub on GitHub and Why use 'virtual' for class properties in Entity Framework model definitions? here on Stack Overflow.

EF core navigation property is null

In EF core, the auto proxies (lazy loading) are disabled by default.

To enable them install package Microsoft.EntityFrameworkCore.Proxies

install-package Microsoft.EntityFrameworkCore.Proxies

and enable them in the option builder

optionsBuilder.UseLazyLoadingProxies();

Is it possible in EF Core to make a one-way navigation property required?

What about adding Role's foreign key to Message and then requiring that property to not be null? Something like:

// MessageConfiguration.cs
builder.Property(b => b.RoleId).IsRequired()

EF Core | Need to use Navigation property for update on one property, but not another (Modules)

From Progman

I did not need to set the Module and FileSystemItemData in my constructor for FileSystemItems:

        /// <summary>
/// Initializes a new instance of the <see cref="FileSystemItems"/> class.
/// </summary>
public FileSystemItems()
{
ItemChildren = new HashSet<FileSystemItems>();
}


Related Topics



Leave a reply



Submit