What is a relationship in EF Core?
A relationship describes how two entity types are associated. EF Core represents relationships using primary keys, foreign keys, and navigation properties.
Entity Framework Core interview questions covering relationships, navigation properties, foreign keys, eager loading, explicit loading, lazy loading and related data.
Open a question for the full answer, code and interview guidance.
A relationship describes how two entity types are associated. EF Core represents relationships using primary keys, foreign keys, and navigation properties.
A navigation property represents a relationship between entities in the object model. A reference navigation points to one related entity, while a collection navigation points to multiple related entities.
A foreign key property stores the key value that links a dependent entity to its principal entity. EF Core can often discover foreign keys by conventions such as CustomerId for a Customer navigation.
A one-to-many relationship means one principal entity can be associated with many dependent entities, while each dependent is associated with one principal.
A one-to-one relationship means one entity is associated with at most one related entity on the other side.
A many-to-many relationship means each entity on either side can relate to multiple entities on the other side. For example, a Student can take many Courses and a Course can have many Students.
Use an explicit join entity when the relationship has its own data or behavior. Examples include enrollment date between Student and Course, quantity between Order and Product, or assigned role between User and Project.
The principal entity is the entity whose key is referenced by the relationship. The dependent entity contains the foreign key that points to the principal.
A required relationship means the dependent must be associated with a principal. For a relational database, the foreign-key column is normally non-nullable.
An optional relationship allows the dependent entity to exist without an associated principal. The foreign-key property is normally nullable.
Relationship configuration typically starts with HasOne or HasMany and continues with WithOne or WithMany. HasForeignKey can explicitly identify the dependent foreign-key property.
Relationship fix-up is EF Core's process of keeping navigation properties and foreign-key values synchronized for tracked entities.
Eager loading retrieves related data as part of the query by using Include and ThenInclude.
Include specifies a related navigation to load with the main query. ThenInclude continues from an included navigation to load another level of related data.
Explicit loading loads related data for an entity after that entity has already been queried and is being tracked.
Lazy loading retrieves related data automatically when a navigation property is accessed. EF Core can support lazy loading through proxies or other configured mechanisms.
The N+1 problem occurs when one query loads a set of parent records and then an additional query is executed for each parent to load related data.
Projection uses Select to retrieve only the columns and related values needed by the application instead of materializing complete entity graphs.
A split query loads certain included collection relationships using multiple SQL queries instead of one large joined query.
A single query retrieves an included entity graph through one SQL query, typically using joins. This avoids the multiple round trips associated with split queries.
Cascade delete means deleting a principal can automatically cause related dependent rows to be deleted when the relationship and database behavior are configured for cascading.
DeleteBehavior controls how EF Core and the database handle a relationship when a principal entity is deleted or a relationship is severed.
A shadow property exists in the EF Core model but not as a CLR property on the entity class. EF Core stores its value in the change tracker.
A self-referencing relationship occurs when an entity type relates to another entity of the same type.
Model relationships according to real business rules and make principal/dependent roles, requiredness, foreign keys, and delete behavior clear. Use explicit Fluent API configuration where conventions are ambiguous.