Table of Contents
Introduction: The Blueprint of Your Data
Recap: The Simple Model
Controlling the Database Schema: Beyond Conventions
Data Annotations: Quick Configuration
4.1. [Key] & [DatabaseGenerated]
4.2. [Table] & [Column]
4.3. [MaxLength] & [StringLength]
4.4. [Required] & [NotMapped]
Fluent API: The Powerhouse of Configuration
5.1. Why Use the Fluent API?
5.2. The OnModelCreating Method
5.3. Common Fluent API Configurations
Configuring the Primary Key
Configuring Table and Column Names
Configuring Data Types and Max Length
Configuring Nullability and Default Values
Adding Database Indexes
The Heart of Data: Modeling Relationships
One-to-Many Relationship (The Most Common)
7.1. Real-Life Scenario: Blogs and Posts
7.2. Defining the Models
7.3. Configuring with Conventions
7.4. Configuring with Fluent API (HasMany().WithOne())
7.5. Understanding Foreign Keys and Shadow Properties
One-to-One Relationship
Many-to-Many Relationship (The Evolved Way)
9.1. Real-Life Scenario: Posts and Tags
9.2. The Old Way: Implicit Join Entity
9.3. The New Way in EF Core 5+: Skip Navigation & UsingEntity
9.4. Configuring the Many-to-Many Relationship
Seeding Data: Populating Your Database with Initial Data
Best Practices, Pros, Cons, and Exception Handling
11.1. Best Practices for Data Modeling
11.2. Exception Handling in Model Configuration
11.3. Pros of EF Core Modeling
11.4. Cons & Alternatives (Dapper, Raw SQL)
Putting It All Together: A Complete Example
Conclusion & What's Next?
1. Introduction: The Blueprint of Your Data
Welcome back, data architects! In our previous part, we mastered the art of CRUD operations—creating, reading, updating, and deleting data. But a powerful application is built on a solid foundation: a well-designed data model. Just as an architect needs a detailed blueprint before construction begins, your application needs a robust data model before it can scale and perform efficiently.
In this part, we will dive deep into the core of Entity Framework Core: Data Modeling and Relationships. We'll move beyond simple classes and learn how to precisely control your database schema, define the intricate connections between your entities, and seed your database with initial data. Get ready to transform from a coder into a data architect!
2. Recap: The Simple Model
Let's start with what we know. In Part 3, we created a simple Blog model.
2.1. The Blog Model Revisited
// Models/Blog.cs
using System.ComponentModel.DataAnnotations;
public class Blog
{
public int BlogId { get; set; } // Convention-based primary key
[Required]
[MaxLength(100)]
public string Title { get; set; }
[MaxLength(500)]
public string Description { get; set; }
public DateTime CreatedOn { get; set; }
}
EF Core uses conventions to infer the database schema from this class. BlogId becomes the primary key, string properties become nvarchar(max) columns, and DateTime becomes a datetime2 column.
But what if conventions aren't enough? What if you need more control?
3. Controlling the Database Schema: Beyond Conventions
3.1. Data Annotations vs. Fluent API
EF Core provides two primary ways to configure your model beyond conventions:
Data Annotations: Attributes applied directly to your model classes and properties. They are simple and keep configuration close to the property.
Fluent API: A set of methods called within the OnModelCreating method in your DbContext. This is more powerful and keeps your model classes clean of EF-specific attributes.
4. Data Annotations: Quick Configuration
Let's enhance our Blog model with Data Annotations for more explicit control.
// Models/Blog.cs
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
[Table("Blogs")] // Explicitly sets the database table name
public class Blog
{
[Key] // Explicitly marks this as the primary key
[DatabaseGenerated(DatabaseGeneratedOption.Identity)] // Specifies the value is generated by the database on add
public int BlogId { get; set; }
[Required]
[StringLength(100)] // Or [MaxLength(100)]
[Column("BlogTitle", TypeName = "varchar(100)")] // Sets column name and data type
public string Title { get; set; }
[MaxLength(500)]
public string Description { get; set; }
[Required]
[DataType(DataType.DateTime)]
public DateTime CreatedOn { get; set; }
[NotMapped] // This property will NOT be mapped to a database column
public string DisplayName => $"{Title} (Created on: {CreatedOn:yyyy-MM-dd})";
}
Key Annotations
[Table]: Overrides the default table name.
[Key]: Defines the primary key.
[DatabaseGenerated]: Controls how the value is generated (Identity, Computed, None).
[Column]: Overrides the column name, data type, and order.
[StringLength] / [MaxLength]: Defines the maximum length for string properties.
[Required]: Makes the property non-nullable in the database.
[NotMapped]: Excludes a property from database mapping.
5. Fluent API: The Powerhouse of Configuration
While Data Annotations are useful, the Fluent API is where EF Core's true configuration power lies.
5.1. Why Use the Fluent API?
Separation of Concerns: Keeps your entity classes clean from persistence-related attributes.
Greater Power: Can configure everything Data Annotations can, plus more advanced scenarios (e.g., composite keys, inheritance mapping, precise index configuration).
Centralized Configuration: All configuration is in one place: the DbContext.
5.2. The OnModelCreating Method
This is where the magic happens. Override this method in your DbContext to use the Fluent API.
// Data/BlogContext.cs
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
public class BlogContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; } // We'll define this soon
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=BloggingApp;Trusted_Connection=True;");
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// All Fluent API configurations go here
modelBuilder.Entity<Blog>(entity =>
{
// We will add configurations inside this block
});
}
}
5.3. Common Fluent API Configurations
Let's configure the Blog entity using the Fluent API, achieving the same result as our Data Annotations, but in a more powerful way.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>(entity =>
{
// Table name
entity.ToTable("Blogs");
// Primary Key
entity.HasKey(b => b.BlogId);
// For composite key: entity.HasKey(b => new { b.Key1, b.Key2 });
// Properties
entity.Property(b => b.BlogId)
.ValueGeneratedOnAdd(); // Identity column
entity.Property(b => b.Title)
.IsRequired() // NOT NULL
.HasMaxLength(100) // nvarchar(100)
.HasColumnName("BlogTitle") // Column name
.HasColumnType("varchar(100)"); // Explicit data type
entity.Property(b => b.Description)
.HasMaxLength(500);
entity.Property(b => b.CreatedOn)
.IsRequired()
.HasDefaultValueSql("GETUTCDATE()"); // Default value in DB
// Indexes
entity.HasIndex(b => b.Title) // Create an index on Title
.HasDatabaseName("IX_Blogs_Title") // Custom index name
.IsUnique(); // Make it a unique index
// Ignore a property (like [NotMapped])
entity.Ignore(b => b.DisplayName);
});
}
6. The Heart of Data: Modeling Relationships
Real-world data is connected. A blog has posts, an author has a bio, a product belongs to categories. These are relationships.
6.1. What are Relationships?
In relational databases, relationships are defined using Foreign Keys. EF Core allows you to define these relationships using your C# classes.
6.2. Navigation Properties: The Glue
Navigation properties are properties in your model that point to related entities. They are the primary way EF Core understands relationships.
Reference Navigation: Points to a single related entity (e.g., Post.Blog).
Collection Navigation: A collection of related entities (e.g., Blog.Posts).
7. One-to-Many Relationship (The Most Common)
This is the most frequent relationship. One entity (the principal) is associated with many other entities (the dependents).
7.1. Real-Life Scenario: Blogs and Posts
One Blog can have many Posts, but a Post belongs to only one Blog.
7.2. Defining the Models
First, we create the Post class and add navigation properties to both Blog and Post.
// Models/Post.cs
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public DateTime PublishedOn { get; set; }
// Foreign Key Property (Optional but recommended)
public int BlogId { get; set; }
// Reference Navigation Property (Links back to the parent Blog)
public Blog Blog { get; set; }
}
// Models/Blog.cs (Updated)
public class Blog
{
public int BlogId { get; set; }
public string Title { get; set; }
// ... other properties ...
// Collection Navigation Property (Links to all related Posts)
public ICollection<Post> Posts { get; set; } = new List<Post>(); // Initialize to avoid null reference exceptions
}
7.3. Configuring with Conventions
EF Core is smart! By simply adding the navigation properties Blog.Posts and Post.Blog, along with the foreign key property Post.BlogId (following the pattern [NavigationPropertyName]Id), EF Core correctly infers a one-to-many relationship.
7.4. Configuring with Fluent API (HasMany().WithOne())
For explicit control, we use the Fluent API. This is especially important if you don't follow the naming conventions.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// ... previous Blog configuration ...
modelBuilder.Entity<Post>(entity =>
{
entity.HasKey(p => p.PostId);
entity.Property(p => p.Title).IsRequired().HasMaxLength(200);
// Define the relationship
entity.HasOne(p => p.Blog) // Post has one Blog
.WithMany(b => b.Posts) // Blog has many Posts
.HasForeignKey(p => p.BlogId) // The foreign key in Post
.OnDelete(DeleteBehavior.Cascade); // What happens when a Blog is deleted?
});
}
DeleteBehavior is critical:
Cascade: Delete the posts when the blog is deleted. (Dangerous but sometimes valid).
Restrict / NoAction: Prevent deletion of a blog if it has any posts. (Safer).
ClientSetNull / SetNull: Set the foreign key to NULL (if it's nullable).
7.5. Understanding Foreign Keys and Shadow Properties
You don't have to define the BlogId property. EF Core can manage it internally as a Shadow Property. However, explicitly defining the foreign key property is considered a best practice because it makes working with related data more efficient and straightforward.
8. One-to-One Relationship
In a one-to-one relationship, one entity is associated with exactly one other entity.
8.1. Real-Life Scenario: Author and AuthorBio
An Author has one AuthorBio, and an AuthorBio belongs to one Author.
8.2. Defining the Models
// Models/Author.cs
public class Author
{
public int AuthorId { get; set; }
public string Name { get; set; }
// Reference Navigation Property
public AuthorBio Bio { get; set; }
}
// Models/AuthorBio.cs
public class AuthorBio
{
public int AuthorBioId { get; set; }
public string Biography { get; set; }
public string? SocialMediaHandle { get; set; } // Nullable property
// Foreign Key Property
public int AuthorId { get; set; }
// Reference Navigation Property
public Author Author { get; set; }
}
8.3. Configuring with Fluent API (HasOne().WithOne())
You must specify which entity is the principal and which is the dependent. The dependent holds the foreign key.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Author>(entity =>
{
entity.HasKey(a => a.AuthorId);
});
modelBuilder.Entity<AuthorBio>(entity =>
{
entity.HasKey(ab => ab.AuthorBioId);
// Define the one-to-one relationship
entity.HasOne(ab => ab.Author) // AuthorBio has one Author
.WithOne(a => a.Bio) // Author has one AuthorBio
.HasForeignKey<AuthorBio>(ab => ab.AuthorId) // The foreign key is in AuthorBio
.OnDelete(DeleteBehavior.Cascade); // If Author is deleted, delete the Bio
});
}
9. Many-to-Many Relationship (The Evolved Way)
This relationship is common when multiple entities can be associated with multiple other entities.
9.1. Real-Life Scenario: Posts and Tags
A Post can have many Tags, and a Tag can be associated with many Posts.
9.2. The Old Way: Implicit Join Entity
Previously, you had to create a join entity (e.g., PostTag) and configure two one-to-many relationships.
9.3. The New Way in EF Core 5+: Skip Navigation & UsingEntity
EF Core 5 introduced a much simpler way to model many-to-many relationships.
9.4. Configuring the Many-to-Many Relationship
// Models/Post.cs (Updated)
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
// ... other properties ...
public int BlogId { get; set; }
public Blog Blog { get; set; }
// Collection Navigation Property for Tags (Skip Navigation)
public ICollection<Tag> Tags { get; set; } = new List<Tag>();
}
// Models/Tag.cs
public class Tag
{
public int TagId { get; set; }
public string Name { get; set; }
// Collection Navigation Property for Posts (Skip Navigation)
public ICollection<Post> Posts { get; set; } = new List<Post>();
}
Now, configure it in the DbContext
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// ... other configurations ...
modelBuilder.Entity<Post>()
.HasMany(p => p.Tags) // Post has many Tags
.WithMany(t => t.Posts) // Tag has many Posts
.UsingEntity<Dictionary<string, object>>( // Configures the join table
"PostTag", // Join table name
j => j.HasOne<Tag>().WithMany().HasForeignKey("TagId"), // Left side
j => j.HasOne<Post>().WithMany().HasForeignKey("PostId"), // Right side
j => j.HasKey("PostId", "TagId")); // Composite primary key for the join table
// You can also configure the join table further, e.g., add a "AddedOn" column.
}
EF Core will create a PostTag table with PostId and TagId columns automatically.
10. Seeding Data: Populating Your Database with Initial Data
You often need initial data (lookup tables, admin users, etc.). EF Core allows you to seed this data directly in your configuration.
10.1. Using HasData in OnModelCreating
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>().HasData(
new Blog { BlogId = 1, Title = "My First Blog", Description = "A blog about learning EF Core", CreatedOn = new DateTime(2023, 1, 1) },
new Blog { BlogId = 2, Title = "Advanced C#", Description = "Deep dives into C# features", CreatedOn = new DateTime(2023, 2, 1) }
);
modelBuilder.Entity<Tag>().HasData(
new Tag { TagId = 1, Name = "EF Core" },
new Tag { TagId = 2, Name = "ASP.NET Core" },
new Tag { TagId = 3, Name = "Tutorial" }
);
}
10.2. Seeding Related Data (The Tricky Part)
To seed data with relationships, you must specify the foreign key values explicitly.
modelBuilder.Entity<Post>().HasData(
new Post { PostId = 1, Title = "Hello EF Core", BlogId = 1, Content = "...", PublishedOn = new DateTime(2023, 1, 2) },
new Post { PostId = 2, Title = "Configuring Relationships", BlogId = 1, Content = "...", PublishedOn = new DateTime(2023, 1, 3) }
);
Important: The primary key values for seeded data must be explicitly provided and are typically static. This data is added when you create a migration.
11. Best Practices, Pros, Cons, and Exception Handling
11.1. Best Practices for Data Modeling
Use Fluent API for Configuration: Keeps entities clean and centralizes configuration.
Always Define Foreign Key Properties: Makes loading and working with related data more efficient.
Be Intentional with DeleteBehavior: Default to Restrict or ClientSetNull to avoid accidental data loss. Use Cascade sparingly.
Use Explicit Data Types: Use .HasColumnType("varchar(100)") instead of default nvarchar(max) for performance.
Initialize Collection Navigations: Use = new List<T>(); to avoid null reference exceptions.
11.2. Exception Handling in Model Configuration
Errors in OnModelCreating are often configuration errors and will appear at runtime when your app starts. Use try-catch blocks in your application startup code (e.g., in Program.cs) to catch these errors gracefully.
try
{
using var scope = app.Services.CreateScope();
var context = scope.ServiceProvider.GetRequiredService<BlogContext>();
context.Database.Migrate(); // This will apply migrations and can throw model configuration errors
}
catch (Exception ex)
{
var logger = app.Services.GetRequiredService<ILogger<Program>>();
logger.LogError(ex, "An error occurred while applying migrations or initializing the database.");
}
11.3. Pros of EF Core Modeling
Productivity: Drastically reduces the amount of database-specific code you need to write.
Maintainability: Changes to the model are reflected in the database via migrations.
Type-Safety: Compile-time checking of your queries and configurations.
Vendor Agnostic: The same model can often be used with different database providers with minimal changes.
11.4. Cons & Alternatives (Dapper, Raw SQL)
Cons
Performance Overhead: Can generate less efficient SQL than hand-written queries.
Complexity: For extremely complex queries or database-specific features, it can be limiting.
Black Box: It's not always obvious what SQL is being generated.
Alternatives
Dapper: A "micro-ORM". It's faster than EF Core for simple queries but requires you to write your own SQL. It's a great choice for performance-critical applications.
Raw ADO.NET: The lowest level, offering maximum control and performance but requiring the most code and manual mapping.
12. Putting It All Together: A Complete Example
Let's look at our final BlogContext with all the configurations.
// Data/BlogContext.cs
public class BlogContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; }
public DbSet<Author> Authors { get; set; }
public DbSet<AuthorBio> AuthorBios { get; set; }
public DbSet<Tag> Tags { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(@"YourConnectionString");
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// Configure Blog
modelBuilder.Entity<Blog>(entity => { ... });
// Configure Post and its one-to-many with Blog
modelBuilder.Entity<Post>(entity => { ... });
// Configure Author and AuthorBio one-to-one
modelBuilder.Entity<Author>(entity => { ... });
modelBuilder.Entity<AuthorBio>(entity => { ... });
// Configure Post and Tag many-to-many
modelBuilder.Entity<Post>()
.HasMany(p => p.Tags)
.WithMany(t => t.Posts)
.UsingEntity<Dictionary<string, object>>("PostTag", ...);
// Seed Data
modelBuilder.Entity<Blog>().HasData(...);
modelBuilder.Entity<Tag>().HasData(...);
}
}
12.2. Generating and Running the Migration
Open the Package Manager Console and run:
Add-Migration InitialCreateWithRelationships
Update-Database
This will generate a migration file that contains all the necessary commands to create the tables, relationships, indexes, and seed data based on your detailed Fluent API configuration. Inspect the generated migration file to see the SQL that will be executed—it's a great learning tool!
13. Conclusion & What's Next?
Congratulations! You have now mastered the art and science of data modeling in Entity Framework Core 9. You can now design complex, real-world data schemas with precise control over tables, columns, indexes, and the three core relationship types. You understand the power of the Fluent API and can even prepopulate your database with essential data.
Your database foundation is now robust, scalable, and well-defined.
In the next part of our series, Part 7: Querying Data with LINQ - The Powerful Way, we will leverage this well-designed data model. We'll explore how to use LINQ to perform powerful, efficient, and type-safe queries against your database, retrieving and shaping the data exactly how your application needs it. Get ready to unlock the full potential of your data!
Powered By : FreeLearning365.com
My Main Article Link : https://www.freelearning365.com/2025/10/entity-framework-core-9-fundamentals.html
📘ASP.NET Core Mastery with Latest Features : 40-Part Series
Join the conversation! Your thoughts help the community grow.