Why would you use projections instead of loading full entities in EF Core queries?

Select(o => new OrderSummaryDto(o.Id, o.Status, o.Total)) returns the fields needed by the API instead of loading the whole Order entity graph.

• Treating EF Core projections into DTOs as a syntax detail instead of a production behavior.
• Not checking generated SQL, query plans, or actual data volume.
• Testing only with tiny local data and assuming production will behave the same.
• Fixing symptoms with caching, timeouts, or retries before understanding the data-access cause.

• Cannot explain how EF Core projections into DTOs affects API behavior.
• Gives only a definition with no practical example.
• Ignores production failure modes.
• Does not know how to verify the behavior.

• How do projections reduce over-fetching?
• When would loading entities be better than projecting DTOs?
• How do projections affect API versioning?
• How would you avoid duplicated projection code?

Listen for practical reasoning about EF Core projections into DTOs. The answer should connect EF Core or SQL mechanics to API behavior, production diagnostics, and trade-offs.

Projection lets the database return only the shape an API needs. It reduces transferred columns and tracking overhead while keeping response contracts separate from persistence entities.