EF codefirst : Should I initialize navigation properties?

by

Collections: It doesn’t matter.

There is a distinct difference between collections and references as navigation properties. A reference is an entity. A collections contains entities. This means that initializing a collection is meaningless in terms of business logic: it does not define an association between entities. Setting a reference does.

So it’s purely a matter of preference whether or not, or how, you initialize embedded lists.

As for the “how”, some people prefer lazy initialization:

private ICollection<Address> _addresses;

public virtual ICollection<Address> Addresses
{ 
    get { return this._addresses ?? (this._addresses = new HashSet<Address>());
}

It prevents null reference exceptions, so it facilitates unit testing and manipulating the collection, but it also prevents unnecessary initialization. The latter may make a difference when a class has relatively many collections. The downside is that it takes relatively much plumbing, esp. when compared to auto properties without initialization. Also, the advent of the null-propagation operator in C# has made it less urgent to initialize collection properties.

…unless explicit loading is applied

The only thing is that initializing collections makes it hard to check whether or not a collection was loaded by Entity Framework. If a collection is initialized, a statement like…

var users = context.Users.ToList();

…will create User objects having empty, not-null Addresses collections (lazy loading aside). Checking whether the collection is loaded requires code like…

var user = users.First();
var isLoaded = context.Entry(user).Collection(c => c.Addresses).IsLoaded;

If the collection is not initialized a simple null check will do. So when selective explicit loading is an important part of your coding practice, i.e. …

if (/*check collection isn't loaded*/)
    context.Entry(user).Collection(c => c.Addresses).Load();

…it may be more convenient not to initialize collection properties.

Reference properties: Don’t

Reference properties are entities, so assigning an empty object to them is meaningful.

Worse, if you initiate them in the constructor, EF won’t overwrite them when materializing your object or by lazy loading. They will always have their initial values until you actively replace them. Worse still, you may even end up saving empty entities in the database!

And there’s another effect: relationship fixup won’t occcur. Relationship fixup is the process by which EF connects all entities in the context by their navigation properties. When a User and a Licence are loaded separately, still User.License will be populated and vice versa. Unless of course, if License was initialized in the constructor. This is also true for 1:n associations. If Address would initialize a User in its constructor, User.Addresses would not be populated!

Entity Framework core

Relationship fixup in Entity Framework core (2.1 at the time of writing) isn’t affected by initialized reference navigation properties in constructors. That is, when users and addresses are pulled from the database separately, the navigation properties are populated.
However, lazy loading does not overwrite initialized reference navigation properties.

In EF-core 3, initializing a reference navigation property prevents Include from working properly.

So, in conclusion, also in EF-core, initializing reference navigation properties in constructors may cause trouble. Don’t do it. It doesn’t make sense anyway.

More Related Contents:

  1. Create code first, many to many, with additional fields in association table
  2. Entity Framework (EF) Code First Cascade Delete for One-to-Zero-or-One relationship
  3. Ignoring a class property in Entity Framework 4.1 Code First
  4. The entity type is not part of the model for the current context
  5. Making Entity Class Closed for Changes
  6. EF Including Other Entities (Generic Repository pattern)
  7. composite key as foreign key
  8. Implementing Zero Or One to Zero Or One relationship in EF Code first by Fluent API
  9. navigation property should be virtual – not required in ef core?
  10. One to one optional relationship using Entity Framework Fluent API
  11. EF Code First: How to get random rows
  12. Entity Framework Code First Lazy Loading
  13. How to declare one to one relationship using Entity Framework 4 Code First (POCO)
  14. Entity Framework – Add Navigation Property Manually
  15. Mapping Database Views to EF 5.0 Code First w/Migrations
  16. Get all associate/composite objects inside an object (in Abstract way)
  17. Optimistic concurrency: IsConcurrencyToken and RowVersion
  18. Place to put Database.SetInitializer
  19. EF4 Code First: how to add a relationship without adding a navigation property
  20. How do I specify that a property should generate a TEXT column rather than an nvarchar(4000)
  21. How to Specify Primary Key Name in EF-Code-First
  22. Entity Framework and multiple schemas
  23. Entity Framework 4.1: Unable to cast from DbQuery to ObjectQuery
  24. Entity Framework: Duplicate Records in Many-to-Many relationship
  25. Mixing Fluent API and DataAnnotations in EF code first
  26. Entity Framework Code First naming conventions – back to plural table names?
  27. The relationship could not be changed because one or more of the foreign-key properties is non nullable
  28. How should I set up my integration tests to use a test database with Entity Framework?
  29. How should I access a computed column in Entity Framework Code First?
  30. How can set a default value constraint with Entity Framework 6 Code First?

Leave a Comment