Entity Framework Core.

EF Core supports two main approaches, Code First and Database First. They differ in which side defines the model, your C# classes or an existing database.

With Code First, you write the entity classes and a DbContext first. Migrations then create the database and change its schema as the classes change. This suits new projects where the team has full control over the data model.

With Database First, you start from an existing database. The Scaffold-DbContext command, or dotnet ef dbcontext scaffold on the CLI, generates the DbContext and entity classes from its tables. This suits existing databases and database-driven development, where the schema is designed first.

Model First belongs to EF6, not EF Core. EF Core has no visual designer and no EDMX model file, so you model in code or start from the database.

An entity is a C# class that EF Core maps to a database table, and each instance of it is one row in that table.

public class Product
{
    public int Id { get; set; }           // Primary key
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int CategoryId { get; set; }
    // Navigation property
    public Category Category { get; set; }
}

By convention, a property named Id or <TypeName>Id becomes the primary key. The other properties map to columns, and Category is a navigation property that points to a related entity.

An entity must be a class, not a struct, and it should have a key. EF Core does not need a parameterless constructor, because it can call a constructor whose parameters match mapped properties. It also maps properties with private setters.

DbContext is the main class you use to work with the database in EF Core. It represents a session with the database and implements the Unit of Work pattern. It collects your changes and writes them together.

It manages the database connection, translates LINQ queries into SQL, and tracks changes to the entities it manages. Each tracked entity has a state such as Added, Modified or Deleted. When you call SaveChanges, the context writes those changes in a transaction.

public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("connection-string");
    }
}

A DbContext is short-lived and not thread-safe, so use one instance per unit of work, such as one web request.

DbSet<T> represents the collection of all entities of one type, and it usually maps to one table. You declare one per entity type on your DbContext, and it is the starting point for queries and changes.

A LINQ query over a DbSet is translated to SQL and runs when you enumerate it. Add, Update and Remove do not touch the database. They set the entity's state in the change tracker, and SaveChanges writes it. The Local property returns the entities the context already tracks, without a new query.

// Querying
var products = context.Products.Where(p => p.Price > 100).ToList();
// Adding
context.Products.Add(new Product { Name = "New Product" });
// Removing
context.Products.Remove(product);
// Local entities
var localProducts = context.Products.Local.ToList();

SaveChanges() blocks the calling thread until the database finishes, while SaveChangesAsync() frees the thread while it waits. The async version returns a Task<int> that you await. Otherwise they do the same work. Both write the tracked changes in one transaction and return the number of entries written.

// Synchronous
int changesCount = context.SaveChanges();
// Asynchronous
changesCount = await context.SaveChangesAsync();

In a web app, a blocked thread cannot serve other requests, so async gives better scalability under high traffic. In a desktop app it keeps the UI responsive. Async does not make a single save faster.

Always await the call before you use the context again. EF Core does not support two operations running at the same time on one DbContext.

Data annotations are attributes you put on entity classes and properties to configure the model. EF Core reads them when it builds the model, so they shape the schema that migrations create.

public class Product
{
    [Key]
    public int ProductId { get; set; }
    [Required]
    [MaxLength(100)]
    public string Name { get; set; }
    [Column(TypeName = "decimal(18,2)")]
    public decimal Price { get; set; }
    [ForeignKey("CategoryId")]
    public Category Category { get; set; }
    [NotMapped]
    public string DisplayName { get; set; }
}

• [Key] marks the primary key
• [Required] makes Name a non-null column
• [MaxLength(100)] sets its length
• [Column(TypeName = ...)] picks the SQL type
• [ForeignKey] names the foreign key behind a navigation
• [NotMapped] leaves a property out of the table

Other common ones are [DatabaseGenerated], [Table] and [InverseProperty]. [Required], [MaxLength] and [Range] also drive validation in ASP.NET Core.

Migrations let you change the database schema step by step to match your entity model, without dropping the database and losing its data. Each migration is a C# class whose Up method applies a change and whose Down method reverts it.

They matter for four reasons.

• The schema history lives in source control next to the code.
• Teammates share schema changes by pulling and applying each other's migrations.
• The same migrations bring development, test and production databases to the same version.
• You can roll back by updating to an earlier migration.

# Add migration
dotnet ef migrations add InitialCreate
# Update database
dotnet ef database update
# Remove last migration
dotnet ef migrations remove