EF Core Relationships

1. The 3 Relationship Types

2. One-to-Many - 90% of Your Job

public class User {
    public int Id { get; set; }
    public List Orders { get; set; } // Navigation
}
public class Order {
    public int Id { get; set; }
    public int UserId { get; set; } // FK
    public User User { get; set; } // Navigation
}

Rule: EF creates FK by convention: UserId → User.Id. Don't fight it.

3. Cascade Delete - The Prod Killer

modelBuilder.Entity()
   .HasOne(o => o.User)
   .WithMany(u => u.Orders)
   .OnDelete(DeleteBehavior.Cascade); // Default!

What happens: _db.Users.Remove(user) → Deletes user AND all his orders.
If wrong: Delete 1 admin = delete 10k orders. Company loses money. You lose job.

1. The Interview Theory: Foreign Keys + Navigation

FK Property: public int UserId { get; set; }. Stores the ID. Required for perf.

Navigation Property: public User User { get; set; }. Lets you write order.User.Name. EF populates via Include.

Shadow FK: If you omit UserId, EF creates UserId column anyway. You can't access it in C#. Avoid. Always define FK explicitly.

2. The #1 Interview Question: "Explain Cascade Delete"

Your Answer: "3 behaviors. 1. Cascade: Delete parent → SQL deletes children. Default for required relationships. Dangerous. 2. Restrict: Delete parent → DB throws FK error if children exist. Safest for prod. 3. SetNull: Delete parent → Child FK set to NULL. Use for optional relations like Order.ShippingAddressId. I use Restrict on invoices, Cascade on blog posts + comments."

3. Many-to-Many - EF Core 5+ vs Old Way

// EF Core 5+ AUTO: Creates StudentCourse join table
public class Student {
    public List Courses { get; set; }
}
public class Course {
    public List Students { get; set; }
}

// Before EF Core 5: Manual join entity needed
public class StudentCourse {
    public int StudentId { get; set; }
    public int CourseId { get; set; }
    public DateTime EnrolledOn { get; set; } // Payload
}

Staff Rule: If join table needs extra columns like EnrolledOn, use manual join entity. Else let EF auto-create.

4. One-to-One - The Unique Index Trick

modelBuilder.Entity()
   .HasOne(u => u.Profile)
   .WithOne(p => p.User)
   .HasForeignKey(p => p.UserId); // FK on dependent

Key: EF creates unique index on UserProfile.UserId. Ensures 1 user = 1 profile. No duplicate.

5. Fix "Multiple Cascade Paths" Error

Error: Introducing FOREIGN KEY constraint may cause cycles or multiple cascade paths

Why: SQL Server dislikes 2 cascade paths to same table. Order → User and Order → Invoice → User.

Fix: Set one path to DeleteBehavior.Restrict or NoAction.