Stop Using Entity Framework Like This: DTO Factories, Micro‑ORM Mirage & How To Model Real Domain Logic With EF Core

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.
• How to separate domain models from read models so EF stops fighting your architecture.

THE CORE INSIGHT

The core insight of this episode is that EF Core isn’t “too heavy” by default—it becomes heavy when you force it to behave like a table copier. Once you treat it as a persistence layer for a real domain model and reserve micro‑ORMs for targeted scenarios, you get the best of both worlds: expressive code and predictable performance without reinventing the plumbing EF already solved.

WHO THIS EPISODE IS FOR

• .NET and EF Core developers frustrated with “bloated” data access layers.
• Architects deciding between Entity Framework and micro‑ORMs in new projects.
• Teams refactoring legacy EF models that are just table mirrors with no behavior.

ABOUT THE AUTHOR / HOST

Mirko Peters is a Microsoft 365, Azure and backend architecture consultant and host of the M365.FM podcast, helping organizations treat data access, domain models and infrastructure as one integrated operating system instead of disconnected layers. He works with teams running on Microsoft 365, Azure and modern .NET stacks to design persistence and domain patterns so Entity Framework, micro‑ORMs and SQL all play to their strengths instead of fighting each other.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.