How to Connect ASP.NET Core MVC with Database using EF Core (DB-First)

Learning .NET + Database for the first time can feel like trying to plug your phone charger into the wrong socket . Don't worry, once you know where the plug goes, it's super easy. In this article, we'll learn how to connect an ASP.NET Core MVC app to a SQL Server database using Entity Framework Core (DB-First approach). Think of it like ordering food online:

The Database is the restaurant, EF Core is the Swiggy/Zomato delivery guy, Your App just places the order and waits for the food (data) to arrive

By the end, you'll have a simple working app that talks to your database .

If you want to learn about EF Core, please read the full article at Understanding Entity Framework in .NET

Getting Started with ASP. NET Core MVC + Database-First Approach

So you've just installed Visual Studio and are staring at that "New Project" dialog, thinking:

"How do I make this thing talk to my database… without blowing it up?"

Don't worry. Today, we'll learn DB-First with Entity Framework Core step by step. Think of EF Core as your Uber driver for data:

You don't drive directly to the SQL Server.
You just tell EF Core your pickup point (connection string) and drop-off (models).
It does the heavy lifting.

Step 1. Create / Open an ASP.NET Core MVC Project

Open Visual Studio ---> New Project .NET Core Web App (Model-View-Controller).

Quick refresher on MVC:

Model → Our data (like Student, Subject).
View → The webpage (HTML, CSS).
Controller → The middleman who listens to clicks and fetches data.

Real-world analogy:

Model = Ingredients
Controller = Chef
View = The delicious dish

Step 2. Install Required NuGet Packages

Open Package Manager Console (or terminal).

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools
dotnet add package Microsoft.EntityFrameworkCore.Design

When we set up database connections in .NET, we need a few special packages. EntityFrameworkCore is like the brain of the system that knows how to manage data. SqlServer acts as the translator, helping our app talk clearly with SQL Server. Tools provides us with the scaffold command, making life easier when we need to generate models from our database. And Design allows Visual Studio to work smoothly with EF Core. Without these, our project is like a car without wheels .it looks fancy, but it just won’t move!

Step 3. Scaffold Models + DbContext from Existing Database

The scaffold command reverse-engineers an existing database and generates two things for us automatically:

Entity classes (one class per table — e.g., Student.cs with properties that map to table columns.
A DbContext class (e.g., ResultDbContext that contains DbSet<T> properties and OnModelCreating mapping code.

In short: it turns the database schema into C# classes so we can use LINQ and DbContext instead of hand-writing raw SQL.

Before we run the command, make sure:

The project builds successfully (scaffolding reads the project & its packages).
If the project is broken, the scaffold will likely fail. We have the needed NuGet packages in the project

Now comes the magic command (run at project root):

dotnet ef dbcontext scaffold 
"Server=Micheal\SQLEXPRESS;Database=ResultManagement;Trusted_Connection=True;TrustServerCertificate=True;" 
Microsoft.EntityFrameworkCore.SqlServer -o Datamodel -c ResultDbContext

What’s happening here:

"Server=.;Database=...;" Database address.
Microsoft.EntityFrameworkCore.SqlServer Provider.
-o Datamodel → Place generated classes inside the Datamodel folder.
-c ResultDbContextName of our DbContext class (we could call it MyUberDb if we like).

Result

EF Core creates classes for each table (e.g., Student.cs, Subject.cs).
And one DbContext (like ResultDbContext.cs).

Think of DbContext as our database remote control. Instead of writing SQL manually, we now say:

_db.Students.ToList();

EF Core silently goes behind the scenes, “SELECT * FROM Students”.

Step 4. Register `DbContext` in `Program.cs`

Before our application runs, we need to register our database context with the Dependency Injection (DI) container in Program.cs.

Add this before `var app = builder.Build();`:

builder.Services.AddDbContext<ResultDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

Why must it go before `app.Build()` and `app.Run()`:

All services (like DbContext) must be registered before the app is built.
If we place it after app.Run(), the app has already started; it won’t know how to inject ResultDbContext, leading to runtime errors like:

“Unable to resolve service for type 'ResultDbContext'...”

Why We Use `AddDbContext` in `Program.cs`

builder.Services.AddDbContext<ResultDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

This does three important things:

Registers ResultDbContext with the DI container
- Tells .NET how to create and manage instances of ResultDbContext.
Configures EF Core to use SQL Server
- The UseSqlServer(...) method sets up the provider and connection string it tells EF Core where and how to connect to the database.
Keeps configuration clean and reusable
- Using builder.Configuration.GetConnectionString("DefaultConnection") Let's change the connection string without touching your code.

In simple terms

AddDbContext tells .NET: “Here’s the database I want to use, and here’s how to connect to it.”

Once registered, anytime our code (like a controller) needs to interact with the database, .NET will automatically inject the configured ResultDbContext.

Why We Store the Connection String in `appsettings.json`

"ConnectionStrings": {
  "DefaultConnection": "Server=Micheal\\SQLEXPRESS;Database=ResultManagement;Trusted_Connection=True;TrustServerCertificate=True;"
}

Advantages

Separation of concerns: Keeps config data separate from code.
Easy environment switching: You can use different connection strings for Development, Testing, and Production.
Security: Avoids hardcoding sensitive data (like usernames or passwords) directly in Program.cs.

It’s like not writing your credit card PIN directly on the card better security and flexibility.

Conclusion

In this Article, we explored how to connect an .NET Core MVC app to SQL Server using EF Core (DB-First approach). By using EF Core, we avoided writing raw SQL and instead used LINQ to query our database in a clean and maintainable way. DB-First is especially powerful when a database already exists. It helps us integrate smoothly and build web apps faster. With the database connection in place, our next step is to create Controllers and Views to perform CRUD operations (Create, Read, Update, Delete), turning our project into a fully functional app.

Remember: DbContext is our remote control, and EF Core is the Uber driver that fetches data for us.