A
[
{},
{}
]
В django rest выдало такую структуру хотя там должно выводится
('name', 'description', 'subscribers') как минимум)
https://dpaste.org/hB43 - вот код
Size: a a a
2020 August 20
J
KM
кто шарит в архитектуре джанги? здесь нужно что-то вынести в services?
M
В сервис бизнес логику выносят обычно
DB
Мне кажется окей. Над фильтром я бы подумал, но он тут совсем маленький: одна из концепций не юзать фильтры в коде, а юзать кастомные кверисеты/менеджеры / селектор-функции
KM
Мне кажется окей. Над фильтром я бы подумал, но он тут совсем маленький: одна из концепций не юзать фильтры в коде, а юзать кастомные кверисеты/менеджеры / селектор-функции
спасибо!
O
Мне кажется окей. Над фильтром я бы подумал, но он тут совсем маленький: одна из концепций не юзать фильтры в коде, а юзать кастомные кверисеты/менеджеры / селектор-функции
Зачем это если оно усложняет код?
KM
DB
Как оно усложняет код? 🤔
O
Как оно усложняет код? 🤔
Разделяет логику которая может быть вписана в обычном фильтре.
DB
Разделяет логику которая может быть вписана в обычном фильтре.
В этом и фишка — рано или поздно в приложении накапливается логика "взять бюджетдату по объекту бюджета" в нескольких местах
DB
А потом оказывается, что теперь бюджетдату надо ещё фильтровать по дате...
O
А потом оказывается, что теперь бюджетдату надо ещё фильтровать по дате...
А это не порождает зависимости?
DB
Какие?
DB
Фишка с кастомными кверисетами — они работают как нативные фильтры, т.е. чейнятся
O
Какие?
Если мне нужно внести изменения в бюджет дату то она по сути везде меняется.
DB
Да, и если придётся что-нибудь поменять — то придётся бегать по всем коду. А с джангой это ещё и нетривиально — не всегда BudgetData появляется из BudgetData.objects
A
Зачем это если оно усложняет код?
он архитектуру делает чище
DB
Если у тебя фильтр в отдельном методе, то его несложно найти и несложно дописать в него ещё логику — она выполнится везде. Из минусов, чтобы это работало нормально, нужно бить себя по рукам за любые фильтры 🤷♂️