Сущность в сессии стоит памяти (снимок для dirty checking) и рискует потянуть ленивые связи. DTO-проекция выбирает ровно нужные поля одним запросом и не управляется сессией.
sottoselect new ...Dto(...), нативные запросыА ещё Read-only транзакции и hint readOnly тоже снижают накладные расходы
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Для чтения отслеживание изменений — чистые накладные расходы: сессия хранит копию каждой сущности, чтобы сравнить её при flush, хотя менять ничего не собираются. Добавьте риск ленивых связей, которые при сериализации превращаются в N+1 или в LazyInitializationException, — и получается, что сущность плохо подходит на роль формата ответа. Проекция (интерфейсная или через конструктор DTO в запросе) выбирает только нужные колонки, поэтому уменьшается и объём выборки, и работа ORM. Дополнительный архитектурный аргумент: DTO отвязывает контракт API от схемы базы, и переименование колонки перестаёт быть ломающим изменением.
Один верный вариант. Подумайте, потом откройте ответ.
Что делает ORM, lazy/eager и proxy, механизм N+1, способы лечения и типичные грабли.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.