Episode Details

If you’re using Entity Framework only to mirror your database tables into DTOs, you’re missing most of what it can actually do. That’s like buying an electric car and never driving it—just plugging your phone into the charger. No wonder so many developers end up frustrated, or decide EF is too heavy and switch to a micro‑ORM. In this episode, I walk through a concrete before‑and‑after refactor, the EF Core features that matter—navigation properties, owned types, fluent API—and the code smells that tell you your EF layer has quietly turned into a DTO factory

WHEN EF BECOMES A DTO FACTORY

Scaffolding tables straight into EF entity classes feels fast: \Customer\\ table becomes \Customer\\ class, one row becomes one object, and at first everything looks clean. But when entities only hold properties and all business rules—totals, discounts, eligibility—get pushed into controllers and services, your “model” stops modeling anything. I explain the red flags: entities with no behavior, duplicated rules across services, controller methods full of business logic and queries that drag back every column because the entity shape is locked to the table. Over time, EF starts to feel like bloat, because you’re carrying a full ORM to do a job a micro‑ORM could handle—while still missing the benefits EF was built to provide.

THE MICRO‑ORM MIRAGE

When EF feels heavy, micro‑ORMs look like salvation: lean, SQL‑first, and transparent. For narrow, read‑heavy endpoints that’s often true, and I explain where tools like Dapper shine—simple queries, tight control of SQL, easy performance tuning. But as soon as your domain needs relationship management, change tracking, concurrency handling or consistent mapping conventions, the work you “saved” comes back as custom plumbing and boilerplate. I outline a simple rule of thumb: reach for a micro‑ORM when you truly need hand‑crafted SQL for slices of your system; default to EF Core when you’re persisting a domain model with real behavior and relationships.

HOW TO USE EF CORE THE WAY IT WAS DESIGNED

EF stops feeling like friction when you let it do the job it was built for: persisting meaningful objects, not table‑shaped shells. I show how to move behavior back into entities, use navigation properties to express relationships, model value objects with owned types and let the fluent API describe database details instead of polluting your domain with attributes. We also talk about where to draw the line between domain models and read models (CQRS), so you don’t bend one set of types into doing everything. Used this way, EF’s features remove code instead of adding it—and the ORM stops being the villain for architectural problems it didn’t create.

WHAT YOU’LL LEARN

• How to spot when Entity Framework has turned into a pure DTO factory.
• When a micro‑ORM like Dapper really is the better fit—and when it isn’t.
• How to use navigation properties, owned types and the fluent API to model behavior and relationships.

  Listen Now