В каком слое DTO объект преобразовывать в словарь перед сохранением в БД?
Приветствую.
Имеем слои: роут, сервис, репо.
В роут приходят данные формы.
В роуте создается DTO-pydantic объект с данными формы.
Из роута DTO передается в сервис.
Из сервиса данные отправляются в репо.
В репо данные должны быть запиханы в модель для БД.
Вопрос: на каком этапе преобразовывать DTO в словарь для маппинга в модель? Какова, она, эта лучшая практика? И что важно — почему так, а не иначе?
DTO можно передать и в репо и обработать в нем. Так до «последнего» сохраняется конкретность/понятность в передаваемых данных. С другой стороны, нужно ли репо знать о DTO вообще? Можно, вообще, в сервисе запилить маппинг в модель, а модель передать в репо, но зачем сервису знать о моделях для сохранения в БД... в общем, недопонимание. Полезным практикам и опыту буду рад.
когда ты с бэка данные отдаёшь куда-либо, например на фронт, тогда и юзай дто, что бы не отдавались лишние поля
для чего в роуте создается дто с данными из формы ? данные из формы тебе надо ток провалидировать и всё, и дальше уже работать с ними либо в сервисе либо в репо, либо и тут и там,где угодно
Я бы отдавал в репозиторий DTOшки. Что там в словаре должно быть и как преобразовывать - это имхо как раз его вопрос, вышележащему коду это знать незачем.
Формировать в сервисном слое ORM модель и передавать ее в репо - плохая идея:
1. Часто приводится аргумент «а вот захочешь ты сменить реляционную БД на nosql и тогда сервисный слой придется переписывать». И хоть это и редкий кейс, тем не менее стоит держать его в голове. Избегайте протекание логики работы с БД в сервисный слой.
2. Само название DTO содержит цель этой сущности - гонять данные между функциями/слоями. Модель ORM это более сложный и более специфичный объект.
Насчет передачи словаря в репо из сервиса тоже есть сомнения:
1. DTO обеспечивает валидацию данных, автодополнение кода, типизацию и еще много что на самом деле - можно писать свои методы, реализующие необходимую логику. Словари - нет.
2. Если вы уже описали DTO, то немного странно использовать его только для передачи данных из роута в сервис. Почему бы тогда не использовать его и для передачи из сервиса в репо?
Резюмируя - передавайте данные между слоями в DTO, в обоих направлениях.
1) Пришел запрос в роутер, делаем ТОЛЬКО базовую валидацию на соответствие полей и их типов, мапим в DTO.
2) DTO передаем в сервис, там делаем бизнес валидацию при необходимости. Мапим DTO в модель, НЕ зависящую от реализации (Postgres, Mysql и тд.).
3) Передаем модель в репо и мапим в ORM-мную модель, делаем все что нужно и в сервис отдаем обычную НЕ ORM-мную модель.
4) В сервисе мапим модель в DTO и отдаем в роутер.
Почему создаем отдельную модель для передачи в репозиторий, а не используем DTO либо ORM-мную модель?
- В DTO может быть много лишних полей, которые не используются в модели, репозиторий не должен ничего знать о них.
- База это адаптер, она должна быть легко сменяема и не влиять на слой сервиса. Создавая промежуточную модель, вместо использования ORM-мной мы изолируем сервис от конкрентной реализации репозитория и базы в целом.
