Architecture

I’ve been there. You join a project, and the first big argument is about the database. One camp wants to stick with the existing, massive SQL Server database and generate code from it (Database-First). The other wants to write C# classes and have Entity Framework Core create the database for them (Code-First).

Picking the wrong one isn’t just a technical mistake; it’s a commitment that can cost your team months of painful refactoring. This happened to me on an e-commerce platform where a premature switch to Code-First crippled our ability to integrate with the company’s legacy inventory system.

Let’s cut through the theory and talk about which approach to choose and when, based on real-world projects.

What’s the Real Difference?

It’s all about the source of truth.

• Database-First: The database schema is the source of truth. You start with an existing database and use a tool to generate your EF Core models (DbContext and entity classes). You never touch the generated model files directly.
• Code-First: Your C# classes are the source of truth. You write your domain models, and EF Core migrations generate and update the database schema to match your code.

Here’s how they stack up in practice.

I’ll never forget the first time I got called at midnight for a performance issue that was my fault. A dashboard in our SaaS app was timing out, and customers were angry. After hours of digging, the culprit was a monster LINQ query generated by Entity Framework Core. It was trying to be clever, but the generated SQL was a performance disaster.

We rewrote that one query using raw SQL with Dapper, and boom: the endpoint went from taking 15 seconds to under 200 milliseconds.

That experience taught me a crucial lesson. The endless debate about EF Core vs. Dapper is asking the wrong question. It’s not about which one is “better.” It’s about knowing which tool to grab for the job at hand. This isn’t about benchmarks; it’s about shipping features that are fast and easy to maintain.

Let’s break down how I decide in the real world.

EF Core: Your Go-To for Business Logic

I start every new project with EF Core. The productivity boost is just too massive to ignore. It shines when your main job is translating complex business rules into code.

Modeling Your Business, Not Just Tables

When your app has real business rules, you want your code to reflect that. EF Core’s mapping for C# objects (POCOs) is fantastic. Features like navigation properties, value objects, and owned types let you build a rich domain model that makes sense.

Think about an Order class. With EF Core, it’s clean and reflects the business.

public class Order
{ …