Installing and Configuring EF Core

Analogy categoryAnalogies

To use EF Core, install the core package Microsoft.EntityFrameworkCore plus a database provider package (e.g., Microsoft.EntityFrameworkCore.SqlServer) via NuGet, and the EF Core CLI tools (dotnet-ef) for design-time operations like generating migrations.

🏏

Cricket analogy: Like assembling a full playing XI you need a base squad (core package), a specialist for a specific pitch such as a spinner for Chepauk (the database provider), and a support staff toolkit (dotnet-ef) to manage selection.

Installing NuGet Packages

You install these with dotnet add package commands: one for the provider (e.g., Microsoft.EntityFrameworkCore.SqlServer) and one for design-time tooling (Microsoft.EntityFrameworkCore.Design), which the dotnet-ef CLI needs to generate and apply migrations.

🏏

Cricket analogy: Like a team manager signing a specific overseas player for the IPL through a transfer window, running dotnet add package Microsoft.EntityFrameworkCore.SqlServer brings in exactly the provider your app needs.

Configuring the Connection String

Connection strings belong in configuration, not source code: store them in appsettings.json under a ConnectionStrings section, then read them at runtime via IConfiguration.GetConnectionString("...") instead of hardcoding them into your DbContext.

🏏

Cricket analogy: Like a team's venue details stored in a fixture sheet rather than hardcoded into the game plan, a connection string lives in appsettings.json and is read at runtime via IConfiguration instead of being hardcoded in C#.

Registering DbContext with Dependency Injection

In Program.cs, you call builder.Services.AddDbContext<TContext>(options => options.UseSqlServer(connectionString)) to register the context with the dependency injection container. By default this registers the DbContext with a Scoped lifetime, meaning one instance is created per HTTP request.

🏏

Cricket analogy: Like assigning a fresh substitute fielder for each innings rather than reusing one for the whole tournament, AddDbContext registers a new DbContext instance scoped to each HTTP request by default.

csharp

// Terminal: install packages
// dotnet add package Microsoft.EntityFrameworkCore.SqlServer
// dotnet add package Microsoft.EntityFrameworkCore.Design
// dotnet tool install --global dotnet-ef

// appsettings.json
// {
//   "ConnectionStrings": {
//     "BookStore": "Server=.;Database=BookStore;Trusted_Connection=True;TrustServerCertificate=True"
//   }
// }

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<BookStoreContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("BookStore")));

var app = builder.Build();

Never commit real connection strings (especially those with passwords) to source control. Use the dotnet user-secrets tool in development and environment variables or a secrets manager (e.g., Azure Key Vault) in production.

Install the EF Core core package plus a provider package (e.g., SqlServer, Npgsql, Sqlite).
Install Microsoft.EntityFrameworkCore.Design and the dotnet-ef global tool for CLI operations like migrations.
Store connection strings in appsettings.json under ConnectionStrings and read them via IConfiguration.
Register your DbContext with AddDbContext in Program.cs, passing the provider's Use* method.
AddDbContext registers the context with a Scoped lifetime by default.
Keep real credentials out of source control; use user-secrets or environment variables instead.