Как дозаполнить корректно поля для Entity при конвертации из DTO?

Question

[dasdasdsadas]

Получаю DTO по API. Далее конвертирую в entity, но откуда мне взять значения тех полей, которых не было в запросе? Как правильно решить эту проблему?

Answer 1

[Орхан Гасанлы]

Добрый день!
Думаю, что вопрос сформулирован некорректно или возможно, я его недопонял.

Итак, насколько я вас понял, то вы хотите обновить существующую запись на основе данных, которые прибежали из контроллера в виде DTO.

Во-первых, в данном случае стоит использовать PutMapping (full updates) или PatchMapping (partial updates)
Читаем подробно тут:
https://www.baeldung.com/http-put-patch-difference...

Во-вторых, после того, как вы получили DTO вам необходимо его замаппить в Entity и обновить в БД. Однако, могут быть поля, которые не были заполнены в DTO и вы не хотите, чтобы они были применены, как null, так?

Далее конвертирую в entity, но откуда мне взять значения тех полей, которых не было в запросе?

Вам не нужно дозаполнять поля сконвертированного entity. Вам необходимо:
1) найти этот entity по идентификатору.
2) Если не хотите, чтобы null поля были применены к сущности, то при маппинге (см. ниже) сделать null check и если поле DTO null, то не сеттить его к сущности.
3) сохранить сущность.

Что касается маппинга:
1) Вы можете использовать интерфейс Converter<S, T>. И для каждого из полей сделать проверку типа (псевдокод):

if (fieldValue != null) { entity.setField(fieldValue); }

2) Если вы используете какую-либо библиотеку для маппинга (modelMapper, MapStruct и др.), то используйте возможности либы. Например, для modelMapper:

modelMapper.getConfiguration().setPropertyCondition(Conditions.isNotNull());

https://stackoverflow.com/questions/45451025/how-t...

Также прокомментирую ваши комментарии из другого ответа:

вот мне интересно, как решается этот вопрос. Разве это нормально, что на каждый пришедший запрос к сервису приходится ходить к базе данных? И это без учета логики!

Можно настроить кеширование и тогда, обращения к БД не будет.

Это базовая ситуация, с которой сталкивается каждый. Допустим у меня entity Person с атрибутом даты рождения, которую я не хочу отображать в PersonDto. Когда пользователь пришлем мне PersonDto по API для, допустим, операции обновления, то как мне при конвертации в entity вернуть эту дату рождения, чтобы я мог сохранить новую сущность?

Обратите внимание на то, что может быть несколько DTO.
Например,
PersonCreationRequest - dto, которое заполняется из фронта при создании юзера
PersonCreationResponse - dto, которое заполняется из бекенда после создания юзера
PersonUpdatingRequest - dto, которое заполняется из фронта при обновлении юзера
PersonUpdatingResponse - dto, которое заполняется из бекенда после обновления юзера
PersonDto - общее dto, которое заполняется из бекенда для других нужд.
Могут быть и другие DTO...
Соответственно, ответ на ваш вопрос - используйте разные DTO.

Не знаю насколько точно смог ответить на ваш вопрос.

Comments

[dasdasdsadas]

Спасибо за подробный ответ, прояснилось множество моментов

Answer 2

[Михаил]

Да ктож знает-то кроме вас? Может быть у вас есть разумные значения по умолчанию. Может быть у вас есть какой-то источник данных (настройки, шаблоны и т.д.). Может быть это вообще ситуация ошибки.

Comments

[dasdasdsadas]

Это базовая ситуация, с которой сталкивается каждый. Допустим у меня entity Person с атрибутом даты рождения, которую я не хочу отображать в PersonDto. Когда пользователь пришлем мне PersonDto по API для, допустим, операции обновления, то как мне при конвертации в entity вернуть эту дату рождения, чтобы я мог сохранить новую сущность?

[Михаил]

dasdasdsadas, странный вопрос. Если у вас есть данные в БД - так прочитайте оттуда.

[dasdasdsadas]

Михаил, это нормально, что для каждого запроса нужно постоянно ходить в базу данных?

[Максим Федоров]

dasdasdsadas, а откуда тогда вы возьмете данные?

[dasdasdsadas]

Максим Федоров, вот мне интересно, как решается этот вопрос. Разве это нормально, что на каждый пришедший запрос к сервису приходится ходить к базе данных? И это без учета логики!

[Михаил]

dasdasdsadas, не хотите ходить в БД на чтение при каждом запросе - не используейте JPA. Возьмите, например, JOOQ - с ним вы можете делать UPDATE полей, которые вам пристали в запросе, не читая предварительно всю запись.

У вас очень абстрактный вопрос. Конкретное же решение зависит от конкретных условий проекта. Если у вас 1000 запросов в час - лишнее чтение из БД вам глубоко безразлично. Если у вас 1000 запросов в секунду - будете оптимизировать везде где можно.