Size: a a a

Django [ru] #STAY HOME

2020 June 19

AG

Artem Gubatenko in Django [ru] #STAY HOME
Artyom Lazovikov
Ребят, подскажите либы для е-каммерс, ну или уже готовые решения. Чтобы опередить выпад в сторону того, что лучше делать всё самому - я уже сделал один е-кам проект сам, теперь хочу облегчить себе жизнь
сам не использовал, но может подойдет:
https://github.com/mirumee/saleor
источник

AL

Artyom Lazovikov in Django [ru] #STAY HOME
Спасибо, попробую
источник

DO

D. Ouhh in Django [ru] #STAY HOME
Muslim Beibytuly
Тогда в services, сделать его пакетом и внутри разные классы с реализацией интерфейсов. DDD - сложно, учитывайте это
api/
services/
  ____init____.py
  utils1.py
  utils2.py
  utils.py
так?
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
Artyom Lazovikov
Спасибо, попробую
напиши потом как тебе, плиз
источник

MB

Muslim Beibytuly in Django [ru] #STAY HOME
D. Ouhh
api/
services/
  ____init____.py
  utils1.py
  utils2.py
  utils.py
так?
Не, на каждую реализацию отдельный файл, не просто utils123. У вас они ведь не беспорядочны, а часть какого-то процесса, продумайте как это проще хранить в коде
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
D. Ouhh
api/
services/
  ____init____.py
  utils1.py
  utils2.py
  utils.py
так?
я старался называть понятно для себя
источник

DO

D. Ouhh in Django [ru] #STAY HOME
ок, спасибо всем за советы!
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
Muslim Beibytuly
Если речь идёт о логике работы с ORM - это надо класть в модель/менеджер/queryset. Если это отдельный внешний сервис - делать services, а вызов  интерфейсов в моделях. App в идеале должен иметь логику одного домена, отдельные app не должны быть вообще связаны как-либо
спасибо, мне тоже будет полезно)
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
Muslim Beibytuly
Если речь идёт о логике работы с ORM - это надо класть в модель/менеджер/queryset. Если это отдельный внешний сервис - делать services, а вызов  интерфейсов в моделях. App в идеале должен иметь логику одного домена, отдельные app не должны быть вообще связаны как-либо
> а вызов  интерфейсов в моделях
только вот это не нравится)
источник

MB

Muslim Beibytuly in Django [ru] #STAY HOME
Artem Gubatenko
> а вызов  интерфейсов в моделях
только вот это не нравится)
Это из-за чистоты кода, если говорить о чистоте философской - сервис уровнем выше, который вызовет и методы модели, и внешние интерфейсы. Более прагматичный подход - Django изначально специально имеет открытый API к собственному ORM на трёх уровнях, чтобы туда можно было подкладывать эту логику. Вызов модели - уже обращение во внешний сервис(бд), так что это не ломает логику самого django
источник

AK

ARTUR KNYAZEV in Django [ru] #STAY HOME
а порядок вывод форм можно котролировать )?
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
Muslim Beibytuly
Это из-за чистоты кода, если говорить о чистоте философской - сервис уровнем выше, который вызовет и методы модели, и внешние интерфейсы. Более прагматичный подход - Django изначально специально имеет открытый API к собственному ORM на трёх уровнях, чтобы туда можно было подкладывать эту логику. Вызов модели - уже обращение во внешний сервис(бд), так что это не ломает логику самого django
первую часть плохо понял)

про модели: изначально я писал всю логику в моделях, и теперь, часто крутя скролл мыши в поисках нужного метода, очень жалею об этом 😃
Из-за этого, сейчас, я стремлюсь оставить моделям только роль "отражения"  таблицы в БД. Ну максимум - простые методы.

Вот мне понравилось твоя мысль про добавление финкционала работы с БД в менеджер или в queryset. Сам я часто про эти возможности забываю.

В итоге: модели и вью - максимально "худые", вся логика в сервисы. Твоя мысль заставила задуматься о других вариантах.
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
ARTUR KNYAZEV
а порядок вывод форм можно котролировать )?
а ты используешь formset?
источник

AK

ARTUR KNYAZEV in Django [ru] #STAY HOME
Да, но строки выводит как ему хочется
источник

AK

ARTUR KNYAZEV in Django [ru] #STAY HOME
fields = {'day','start','end','usermaster'} я хочу так
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
ARTUR KNYAZEV
Да, но строки выводит как ему хочется
там если выводишь данные из БД, то добавь нужную сортировку в запрос
источник

AG

Artem Gubatenko in Django [ru] #STAY HOME
ARTUR KNYAZEV
fields = {'day','start','end','usermaster'} я хочу так
поля что-ли?
источник

AK

ARTUR KNYAZEV in Django [ru] #STAY HOME
да
источник

AK

ARTUR KNYAZEV in Django [ru] #STAY HOME
)))
источник

MB

Muslim Beibytuly in Django [ru] #STAY HOME
Artem Gubatenko
первую часть плохо понял)

про модели: изначально я писал всю логику в моделях, и теперь, часто крутя скролл мыши в поисках нужного метода, очень жалею об этом 😃
Из-за этого, сейчас, я стремлюсь оставить моделям только роль "отражения"  таблицы в БД. Ну максимум - простые методы.

Вот мне понравилось твоя мысль про добавление финкционала работы с БД в менеджер или в queryset. Сам я часто про эти возможности забываю.

В итоге: модели и вью - максимально "худые", вся логика в сервисы. Твоя мысль заставила задуматься о других вариантах.
Это уже мы сами контролируем - модели тоже можно делить. Мы изначально каждую модель держим в отдельном файле, в init.py перечисляем. Очень редко(1 в 3 года) появлялась модель, в которой и manager, и queryset выделяли отдельно и импортировали локально, много логики фильтрации и считаемых на лету значений. Создали пакет по названию модели, импортировали там уже только модель. Так держим жесткие <300 строк на файл, с поиском по проекту проблем пока не возникало
источник