For a read-only list screen, why would you project query results into DTOs rather than loading the mapped entities and reading their fields?

## The hidden bill on a managed entity When a query returns entities, Hibernate does considerably more than materialise objects. **It selects every mapped column.** The SQL for `select o from Order o` lists all basic properties plus the foreign keys of to-one associations, and if any association is mapped `FetchType.EAGER` it joins or issues extra selects for those too. A grid that shows id, date, customer name and total may be dragging a `text` description column and a serialized payload across the wire for every row. **It stores each entity in the persistence context**, keyed by identity, so the session can guarantee that one row equals one object. **It stores a loaded-state snapshot** alongside — an array of the property values as they were read. This exists solely so that at flush time Hibernate can compare current values against the snapshot and generate UPDATEs for what changed. So a read of N rows with M columns costs roughly 2×N×M values retained until the session ends or is cleared. **It pays that comparison at every flush.** Automatic dirty checking iterates the managed entities and compares property by property. Nothing was modified, but the work is done anyway, and it grows with the size of the context, not with the size of your change. ## What a DTO projection changes ```sql select o.id, o.created_at, c.name, o.total from orders o join customers c on c.id = o.customer_id where o.status = ? ``` One narrow row per result, one small object per row, no context entry, no snapshot, no flush participation, no cascade, no interaction with the second-level entity cache. The result is a value: immutable if you use a record, safe to hand to a serializer, safe to cache in your own layer, and impossible to accidentally mutate into an UPDATE. ## The correctness arguments, not just the performance ones **Accidental writes.** A managed entity is a write handle. Any code path that calls a setter — a mapper normalising a value, a formatter trimming a string — produces an UPDATE at the next flush. Read models cannot do this by construction. **Uncontrolled query fan-out.** Rendering a list from entities tempts navigation into associations, and each navigation on a lazy association is another query per row. A projection has to name every value up front, which forces the join to be explicit and the row count to be predictable — the N+1 problem is designed out rather than watched for. **Explicit contract.** The DTO's field list *is* the read contract. When a UI field is dropped, the projection changes and the SQL narrows. With entities, nobody can tell which columns a screen actually uses, so nothing can ever be safely made lazy or removed. **Stability under mapping change.** Adding a heavy column to an entity silently slows every entity-returning query in the system. Projections are unaffected unless you ask for the new column. ## When entities are still right This is not "never load entities". Load them when you intend to **change** something: that is what the persistence context, dirty checking and cascades are for, and hand-writing UPDATE statements to avoid them is a much worse trade. Load them for small results where the difference is immaterial and the code is simpler. Load them when domain behaviour — invariants, methods on the aggregate — has to run. The rule of thumb that survives review: **command paths load entities; query paths project.** The bigger the result set and the wider the entity, the more decisive the rule becomes. ## Middle grounds, and their limits - **Read-only sessions/queries.** Hibernate can mark results read-only (for example `org.hibernate.readOnly`), which skips the snapshot and dirty checking. That removes the flush cost but not the wide select, and the objects still occupy the context. - **Lazy basic attributes.** Bytecode enhancement can make a heavy column lazy, narrowing the select — powerful, but it needs enhancement configured and applies globally to that attribute. - **Clearing the session** between batches bounds memory but does nothing for the columns you read. A projection addresses all of it at once and needs no configuration, which is why it is the default for read models. ## The counterargument to answer in an interview Someone will say projections duplicate the model and multiply classes. The honest answer: yes, a DTO per read use case is more classes, and that is the point — each states exactly one screen's needs and can change with that screen without touching the domain model. The failure mode to avoid is one shared "fat DTO" that unions every screen's fields, which reproduces the entity's problems without its benefits.