Should an ASP.NET Core API use the same class for request DTOs, domain objects, and EF Core entities?

Separate API, domain, and persistence models deliberately

Uses separate models where they protect contracts, invariants, or storage evolution while avoiding repetitive mapping with no boundary value.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Request DTOs define what callers may send and prevent accidental over-posting. Response DTOs shape the public contract without exposing navigation properties or internal fields. Domain types protect business invariants, while persistence models reflect database mapping when that shape would distort the domain. For simple CRUD with little behavior, using an EF entity internally and projecting to API DTOs may be enough.

Full answer below

Practice focus

Public contracts, over-posting, domain invariants, persistence mapping, projections, versioning, and mapping trade-offs.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
One class can be convenient, but it couples public input, business behavior, and storage shape. I separate models when those responsibilities have different constraints or reasons to change.
Request DTOs define what callers may send and prevent accidental over-posting. Response DTOs shape the public contract without exposing navigation properties or internal fields. Domain types protect business invariants, while persistence models reflect database mapping when that shape would distort the domain. For simple CRUD with little behavior, using an EF entity internally and projecting to API DTOs may be enough.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I map at boundaries and avoid automatic mapping that hides important decisions. Commands turn validated request data into domain operations; queries can project directly from EF Core into response models. I do not load a full entity graph only to map it afterward. Separate types are most valuable when API versioning, security, invariants, or schema evolution differ. Repeating identical types across every layer without protecting anything is just maintenance cost.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning EF entities directly from controllers.
Binding public requests to every writable entity property.
Using reflection mapping without reviewing sensitive fields.
Creating duplicate models that never diverge or protect a boundary.

Should an ASP.NET Core API use the same class for request DTOs, domain objects, and EF Core entities?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement