AO
на его примерах оно нормально
Size: a a a
2019 May 07
s
а так пох, был вопрос вот пример: тип не надо мучить жопу))
AO
классический подход, связанный с архитектурой бизнес-логики в Django - то, что связано с конкретным объектом, нужно запихнуть в модель, а то, что связано с несколькими - в менеджеры
AO
подход, который сейчас пробивается в свет - а давайте делать сервисы и выносить это туда
AO
он кажется удобнее в ряде случаев (когда есть что-то, что связано с 2-3 моделями сразу)
AO
его минусы - полная несовместимость с DRF в его текущем виде
AO
DRF хочет модели, а не какие-то там сервисы
s
его минусы - полная несовместимость с DRF в его текущем виде
есть предложение намутить видос или статейку, обязательно почитаю
t
Ну не обязательно же юзать ModelSerializer
t
Можно сделать ServiceSerializer))
AO
тут просто получится так, что проще какой-нибудь другой апп сделать, чем DRF адаптировать
AO
тем более вот эти все асинхронные вещи добавятся в 3 джанго
AO
сразу над ними
AO
DRF реально прикольный именно своими ViewSet'ами, над которыми автоматически генерится схема OpenAPI
AO
то есть добавил эти ViewSet'ы, добавил фильтры и drf-yasg сгенерил по ним схему сам
AO
если мы вдруг приходим к тому, что такого удобства мы лишаемся, то сразу вопрос о том, а не выкинуть ли всё это, а не сделать ли как-то лучше/проще, взяв опыт DRF за основу
AO
и сразу с упором на генерацию нормальной OpenAPI схемы по сервисам
t
ну да, согласен))
AO
в любом случае, после 3 джанги начнут пытаться делать API над асинхронными вьюшками, вот нужно, чтобы они поддерживали именно эту работу с сервисами, а не с моделями
AM
DRF хочет модели, а не какие-то там сервисы
Надо мне срочно доку обновлять. А то мы и в drf и в сервисы умеем, но забыли про это рассказать. 🤦♂️