🔑 Keys in EF Core

✅ 1. Primary Key (PK)

Definition: Uniquely identifies each entity. Default Convention: Property named Id or <EntityName>Id. Explicit Definition: Data Annotation: [Key]
public int ProductId { get; set; } Fluent API: modelBuilder.Entity<Product>()
.HasKey(p => p.ProductId);

✅ 2. Composite Key

modelBuilder.Entity<OrderDetail>()
.HasKey(od => new { od.OrderId, od.ProductId });
⚠️ Must be defined using Fluent API (Data Annotations don’t support composite keys).

✅ 3. Alternate Key

modelBuilder.Entity<Product>()
.HasAlternateKey(p => p.Sku);

✅ Primary Key vs Alternate Key

Feature Primary Key Alternate Key
Uniquely identifies? ✅ Yes ✅ Yes
Required? ✅ Yes ❌ Optional
Can be used as FK? ✅ Yes ✅ Yes (with .HasPrincipalKey)

✅ 4. Foreign Key (FK)

modelBuilder.Entity<Employee>()
.HasOne(e => e.Department)
.WithMany(d => d.Employees)
.HasForeignKey(e => e.DepartmentId);

✅ 5. Composite Foreign Key

modelBuilder.Entity<OrderDetail>()
.HasOne(od => od.Product)
.WithMany()
.HasForeignKey(od => new { od.ProductId, od.SupplierId });

✅ 6. Shadow Properties & Shadow Foreign Keys

Shadow Property: modelBuilder.Entity<Order>()
.Property<int>("ShadowCustomerId"); Shadow FK: modelBuilder.Entity<Order>()
.HasOne(typeof(Customer))
.WithMany()
.HasForeignKey("ShadowCustomerId");

✅ 7. Alternate Key as Principal in FK

modelBuilder.Entity<Product>()
.HasAlternateKey(p => p.Sku);

modelBuilder.Entity<OrderDetail>()
.HasOne(od => od.Product)
.WithMany()
.HasForeignKey(od => od.ProductSku)
.HasPrincipalKey(p => p.Sku);

✅ 8. Keyless Entities

modelBuilder.Entity<MyView>().HasNoKey();
  • Cannot be updated, inserted, or deleted.
  • Cannot participate in relationships.

✅ 9. Unique Constraints Across Multiple Columns

modelBuilder.Entity<User>()
.HasAlternateKey(u => new { u.Email, u.Username }); Or using Index: modelBuilder.Entity<User>()
.HasIndex(u => u.Email)
.IsUnique();
👉 .HasIndex() creates an index (performance), .HasAlternateKey() enforces uniqueness in EF model.

✅ 10. Common Errors and Gotchas

SituationOutcome/Error
No PK defined❌ Runtime error
Changing PK in migration❌ Drops table → risk of data loss
Nullable FK with .OnDelete(SetNull)❌ Error if FK is non-nullable
FK type mismatch❌ Runtime exception
Optional FK in composite key❌ Not allowed
Required navigation with optional FK❌ Invalid – must match nullability

✅ 11. Key Usage in Change Tracking

For composite keys, all values must match for EF Core to treat two entities as the same in the ChangeTracker.

✅ 12. Fluent API vs Data Annotations

FeatureFluent APIData Annotations
Flexibility✅ High❌ Limited
Composite Keys✅ Yes❌ Not supported
Precedence✅ Overrides Data Annotations❌ Can be overridden

✅ 13. GUID as Primary Key

  • Pros: Globally unique, useful in distributed systems.
  • Cons: Poor for clustered indexes (fragmentation). Use NEWSEQUENTIALID() for better performance.
modelBuilder.Entity<User>()
.Property(u => u.UserId)
.HasDefaultValueSql("NEWSEQUENTIALID()");

✅ 14. Renaming Foreign Key Constraint

modelBuilder.Entity<Employee>()
.HasOne(e => e.Department)
.WithMany()
.HasForeignKey(e => e.DepartmentId)
.HasConstraintName("FK_Employee_Department");

✅ 15. Default Key Generation Strategies

modelBuilder.Entity<Product>()
.Property(p => p.ProductId)
.ValueGeneratedOnAdd();
  • .ValueGeneratedOnAdd() → Auto-increment/identity.
  • .ValueGeneratedNever() → Must be set manually.
  • .ValueGeneratedOnAddOrUpdate() → For computed columns.

✅ 16. Owned Entities and Keys

modelBuilder.Entity<Order>()
.OwnsOne(o => o.ShippingAddress);

Owned types share the same PK as the owner.

✅ 17. Summary Table

ConceptDescriptionExample
Primary KeyUnique identity.HasKey(x => x.Id)
Composite KeyMultiple properties as PK.HasKey(x => new { x.A, x.B })
Alternate KeyAdditional unique constraint.HasAlternateKey(x => x.Email)
Foreign KeyConnects entities.HasForeignKey()
Shadow PropertyNot in class but in EF model.Property<string>("Code")
Shadow FKFK property not in class.HasForeignKey("CustomerId")
Keyless EntityNo primary key.HasNoKey()
Rename FKCustom FK name.HasConstraintName("FK_Custom")
GUID as PKUnique but fragmented indexUse NEWSEQUENTIALID()
Default Key StrategyConfigure key generation.ValueGeneratedOnAdd()
Owned Entity KeyShares owner’s PK.OwnsOne(...)

✅ 18. Final Tip

👉 Best Practice: Define keys clearly in your model from the beginning. Avoid changing PK/AK definitions after production to prevent migration issues and data loss.

Comments

Post a Comment

Popular posts from this blog

Logging in .NET Core: Built-in Logging vs Serilog with Full Implementation Guide

Logging in .NET Core: Built-in Logging vs Serilog with Full Implementation Guide Logging is an essential aspect of application development. In .NET Core and beyond (.NET 5/6/7/8), Microsoft provides a built-in logging framework that is simple to use. However, when applications grow and logging needs become more advanced, third-party solutions like Serilog shine. In this blog, we will explore built-in logging, Serilog, their differences, and how to implement both in your .NET Core application.   1. .NET Core Built-in Logging Overview .NET Core uses Microsoft.Extensions.Logging as a base logging interface. This logging abstraction allows logging to multiple destinations, such as: Console Debug EventSource EventLog (Windows only) Azure Application Insights (via extensions) Files (through third-party integrations) Pros: Simple to use Built-in Fully integrated with Dependency Injection (DI) Cons: Limited formatting op...
Read more

Factory Method Design Pattern in .NET — Real-Time Finance Example

The Factory Method design pattern is a classic solution for a common software engineering challenge: how to create objects without tightly coupling the client code to their concrete types. Instead of instantiating classes directly using new, Factory Method defers object creation to subclasses or dedicated factory methods. In this blog post, we'll explore the Factory Method pattern in C# with a real-world banking transaction example and also discuss its benefits, drawbacks, and best practices.   💡 What Is the Factory Method Pattern? The Factory Method pattern provides an interface for creating objects in a superclass but allows subclasses or factory methods to alter the type of objects that will be created . This promotes: Loose coupling Polymorphism Improved testability and scalability   🎯 Purpose The key goal of Factory Method is to encapsulate object creation logic , so your business logic doesn’t depend on concrete classes. This becomes especially valuable...
Read more

Implementing Single Sign-On (SSO) in .NET Core and Angular

Implementing Single Sign-On (SSO) in .NET Core and Angular Introduction Single Sign-On (SSO) is a powerful authentication mechanism that enhances user experience and security by allowing users to log in once and access multiple applications without re-entering credentials. In this blog, we will walk through the implementation of SSO using OAuth 2.0 and OpenID Connect (OIDC) with IdentityServer4 in .NET Core and Angular. Why Use SSO? Improved User Experience : Users authenticate once and access multiple services without repeated logins. Centralized Authentication : Easier user management and security enforcement. Better Security : Reduces password fatigue and encourages strong authentication policies. Scalability : Works well across multiple applications, making it ideal for enterprise solutions. Step 1: Setting Up IdentityServer4 in .NET Core IdentityServer4 is an open-source framework that enables authentication and authorization using OpenID Connect and OAuth2. 1.1 Cr...
Read more