Сегодня закончил проходить один неплохой курс по Django, чтобы реализовать свой петпроджект. Сел за "чистый лист" и понял, что понятия не имею, как правильно организовать архитектуру приложения с учетом обработки бизнес-логики. Почему-то этот вопрос в курсе обойден стороной (а точнее там все зафигачили во вьюху). Посмотрел твое видео - и в голове все встало на свои места. Большое спасибо, очень ценно!
смотри в сторону паттернов. Типа Репозитории Dry.... Когда нужно использовать и когда не нужно. Паттерны написаны кровью и пОтом разрабов, рекомендую. После изучения паттернов поймешь что джанго это то еще говно с коробки.
Правильно нарвался на видос)) не будешь совершать наших новичковских ошибок)) Вот сейчас решил глянуть на свой старый проект, а там одна вьюшка на 285 строк кода, другая на 176))) не надо так))
В PyCharm используй Shift+F6 для переименования функций и классов. Иначе при частых переименованиях очень легко поломать код в каком-то месте, просто, потому что забыл там переименовать (и даже об этом знать не будешь). А заодно расскажи про это новичкам. Это будет очень полезный для них совет.
Вот это реально сейчас пригодилось , ибо начал переписывать старый проект и после просмотра понял , что допустил кучу ошибок даже в новой версии, спасибо , очень помогло
Отличное видео. Очень жалею, что не посмотрел его раньше, потому что мне пришлось до концепции отделения бизнес-логики доходить самому очень кровавым и долгим путем. А тут бац: и всё готовое, пользуйся на здоровье. Спасибо вам огромное за ваш труд! Однозначно лайк :).
Видео отличное, из серии "ответы на вопросы, которые вы боялись спросить")) Но буду рад услышать совет - я, к сожалению, не питонист, а node.jsник, но принципы там очень схожи. Так вот: 1) У тебя бизнес логика для рассылок жестко привязана к mailchimp. А что если завтра прийдеться перейти на другой сервис рассылок? Везде рефакторить импорт и названия? Хоть я и не верю что наступит это "завтра", но в общем случае рекомендуют создавать интерфейс по типу IEmailService, и чтобы mailchimp сервис реализовывал его. Вопрос: что с этим делать, и как вы реализовываете это в питоне? 2) Могут ли сервисы импортировать другие сервисы? Ответ скорее всего да, но как в таком случае тестировать отдельные сервисы? Обычно применяют dependency injection, но можно ли без него обойтись? Заранее спасибо.
Приветствую! Для начала хотел поблагодарить за контент и выразить свою признательность за тот вклад, который Алексей делает в сфере популяризации и развития индустрии. Мне одному кажется, что в последнее время очень много внимания уделяется комментированию и именованию переменных, совсем позабыв о значимости методик моделирования и интерпретации кода как такового. Нет, я не говорю, что комментировать код не нужно, - нужно!!! и причем обязательно. В последнее время, лично у меня, сложилось ощущение, что все аля тимЛиды и сеньёры сговорились, пытаясь навязать мнимые ценности джунам, маскируя облегчение собственноручного код ревью, под «Паттерны комментирования». А теперь внесу свои пару капель дегтя в бочку меда: 1. GET запросами оформлять почтовые подписки? Серьезно? 2. По сути задачи 2 представления можно было бы отменить в 1, тем самым, применение DRY выглядело бы поубедительнее. Выделяя case_id = None(общие подписки) мы можем ограничиться одной моделью и одним представлением, тем самым «развязывая себе руки» для более высокоуровневого манипулирования сущностями. 3. Django.forms на мой взгляд решает все те проблемы, которые были размазаны между views.py(валидация) и services.py(логика) … Хотя тут уже больше вопрос вкусовщины… 4. CBV… Всегда стараюсь отдать предпочтения именно им, только если не стоит вопрос производительности. Но на таких задачах только они. Как отработает представление, если запрос будет POST,PUT? Что будет, если для каждой передаваемой переменной нужно удалить пробелы? Ну и тд…. 5. Settings.py Ну если мы бьемся за минимизацию количества строк в файле, то мб переменные mailcamp вынести в отдельный файл(аля mailcamp_settings.py), а в settings.py сделать импорт? 6. Настоятельно не рекомендую делать запросы к сторонним сервисам в рамках синхронного запроса. Это вешает сервис….причем как правило каскад сервисов… Но это уже другая история.. Алексей еще раз благодарю за контент!! Делать познавательные видео, гораздо полезнее и познавательнее, чем писать критикующие каменты!
Спасибо за развернутый комментарий! > GET запросами оформлять почтовые подписки? Серьезно? Вьюшка из видео обработает и POST запрос, но мейл в данном случае передан в GET параметре, да. Я не считаю, что жёсткое следование REST в этом конкретном примере столь важно. > По сути задачи 2 представления можно было бы отменить в 1 Можно, но я не сказал бы, что две эти задачи настолько схожи, что имеет смысл объединить их в одну вьюшку. Подписки на разные сущности вполне подвержены потенциально разной логике обработки (как минимум будет проверка наличия Case, в будущем может появиться еще что-то, например, проверка авторов, относящихся к Case, и навешивание отдельных тегов в Mailchimp подписывающемуся). Если у нас 2 вьюшки - разный код будет в разных вьюшках, если у нас 1 вюьшка - то в ней неминуемо будут появляться куча if ветвлений, что усложнит логику, усложнит чтение и поддержку кода. Помимо DRY есть еще KISS:) Возможно я бы сделал CBV с наследованием, но опять же не уверен, что это здесь оправдано. > Django.forms на мой взгляд решает все те проблемы Я не считаю правильным использовать формы для чего-то, выходящего за рамки работы с формами. > CBV… Всегда стараюсь отдать предпочтения именно им Нормально, почему нет. Я тоже люблю CBV, как раз туда проверку исключений добавить в базовый класс и тд. > settings.py Можно, но выносить несколько строк кода в отдельный файл не уверен, что оправдано. Если конфигов прям много-много, тогда да. Но на практике такого не видел, чтобы конфигов в одном settings.py было столь много, чтобы это перестало быть комфортным. > Настоятельно не рекомендую делать запросы к сторонним сервисам в рамках синхронного запроса Да, конечно, тем более в синхронной джанге. Но это действительно другая история, не про БЛ. Спасибо:)!
Диджитализируй! Спасибо за ответ!) Я не придерживаюсь позиции rest, тут какбы позиция реализации http: если основной результат выполнения запроса запись в хранилище, то post исправление put и тд. Эти рекомендации были задолго до появления rest. «Нет ничего более постоянного, чем временное» и «проект нельзя закончить, это как ремонт в своей квартире: можно только остановить»
а будет тематика о тестировании? интересно было бы послушать, unittest, pytest, best practice всяких теорий полно, а практики совсем мало, особенно что касаемо Джанго API
Отличный выпуск! Хорошо все рассказал и показал - красавчик! Получился неплохой пример написания кода. Причем есть даже такая практика - сначала пишем как попало (если не можем определиться с архитектурой и структурой на "берегу"), а потом рефакторим, чтобы не делать "равиолли-код" и избежать "оверинженеринга" (правда, это скорее для новичков - у опытных разработчиков почти все получается сразу). P.S.: Но опыт не пропьешь - написать вьюшку начинающего junior-а не получилось (всеравно чувствуются хорошие привычки) ;). Я обычно не пишу комментарии, а сейчас отвлекся и вместо того, чтобы дописать сообщение к коммиту - пишу комментарий ;) Ещё правда есть пару вопросов, не обессуть ;) Disclaimer: цель данного комментария узнать мнения автора видео. Он не имеет задачи задеть чьи-либо религиозные чувства (в том числе в нейминге) и породить священную войну в ответах под собой. Автор комментария так же не является "троллем" и просто хочет узнать мнения автора видео. 1. Почему services, а не logic? Я понимаю, вкусовщина, но просто интересно твое мнение. У меня при виде services сразу в мыслях, что там код какого-то сервиса, а не бизнес-логика пакета. Хотя я бы положил работу с клиентом mailchamp (mailchamps_services) куда-нибудь в utils. Причем, можно даже на уровне проекта, а не приложения - так оно будет доступно для всех пакетов, если понадобится. Уж очень это похоже на шорткаты. Хотя кто-то говорит, что utils - это зло, потому что мы складываем туда все, что неможем отнести к какому-то модулю. Логику самого приложения (services.py у тебя) я бы закинул в logic.py (но тут просто различие в названии). Вообще правильный нейминг это холиварная тема (правда тут у каждого своя - главное, чтобы было понятно), поэтому можешь не отвечать ;). P.S.: Зря, зря я написал этот вопрос, но дюже интересно узнать твое мнение. 2. Как ты относишься к логике в django-rest-framework (DRF) фильтрах и сериализерах если речь идет не о логике сериализации/фильтрации? Ну самое элементарное это методы create/update в сериализерах DRF, вместо вызова функций логики сохранения (простой или сложной) непосредственно во view функции? P.P.S.: Жирноватый комментарий получился, спасибо всем кто дочитал до конца и прошу прощения за потраченное время и ресур вашего зрения ;). Ещё раз повторюсь, что нехочу никого обидеть (особенно автора видео) и если так получилось, то за это тоже прошу прощения. Так же прошу прощения за переход с автором видео на "ты" без его разрешения. Но проще просить прощения, чем разрешения (Zen Python) - так что можно бросить в меня Exception ;) И ещё раз хочу сказать спасибо за видео и за канал в целом. Для новичков (да и не только) это очень полезный формат, потому что увидеть как опытные разработчики программируют и мыслят мало где можно. Есть, конечно github, но в хороших проектах с хорошим кодом новичку будет трудно разбираться и понимать мотивацию, а здесь все доступно, понятно и с комментариями (как говорится то, чему не учат в школе и даже в университете ;)). Ещё раз спасибо - продолжай в том же духе, ты делаешь полезное дело!
@@trytoStopTV Здравствуйте! Вы задали очень интересный вопрос, и чтобы на него ответить я ещё раз открыл PEP 20 в поисках "Easier to ask for forgiveness than permission" и.... не нашел. Для меня это было странно, я так привык к этому принципу, который для меня казался не отделимым от Python, что начал пытаться вспомнить, где я его видел. Через пару минут до меня дошло, когда я нашел его упоминание в "глоссарии" python - это принцип EAFP. Рука - лицо. Стыдно. Но теперь выпавшее звено встало на свое место. А Вам хочу сказать спасибо - теперь не буду ссылаться на Zen упоминая эту фразу (конечно, если опять не забуду, что это перевод расшифровки EAFP принципа...).
Третий или четвертый раз смотрю это видео. И только сейчас словил инсайт про хранение паролей в переменных окружения. Это же очень удобно, и не нужно париться, что конфиг с паролями улетит в репозиторий. Прям душевно благодарю за видео 🔥🔥🔥🔥🔥
Отличный выпуск! Как впрочем и всегда) Очень правильный подход показать как сделать плохо и поэтапно указать на ошибки и способы их исправить, соответственно и рефакторинг кода. Ещё раз подчеркивает важность не торопиться и не забивать так же на проектирование и продумывание логики, а не кидаться сразу в код и что-то писать... В общем, выпуск супер!
Я интуитивно пришёл к тому же, только осмыслить был не в состоянии. Казалось, что я просто отсебятину делаю и просто плохо усвоил джангу. А оказалось, все правильно. Респект. Все понятно. Термин services возьму на вооружение
Здравствуйте, спасибо большое за видео ролик, вы очень хорошо объяснили как правильно делать и мне как новичок в Back-end разработке очень было понятно и полезно, ещё раз спасибо 🙏
Спасибо вам огромное за полезные ролики. Недавно начал вас смотреть(являюсь junior full-stack developer-ом). Написал свой интернет-магазин, но после просмотра последних 2х видео про бизнес-логику, осознал, насколько неправильно подошел к данному вопросу(тупо копировал код из одной вьюшки в другую). Открываете глаза на программирование в целом. Спасибо огромное! C нетерпением жду выпуска следующих видосов:)
Приятно смотреть на человека, который понимает что он делает и хорошо владеет инструментом(языком программирования). Пишу на .net, но код читался, как песня.
Сколько полезной информации на вашем канале я получил не сосчитать, а сколько еще осталось). Спасибо за труд, все стало на свои места после вашего наглядного примера. Всех благ!🔥
Не подскажешь? А файл mailchimp_services не нарушает принцип независимости приложений? Написан в одном приложении, другое его импортирует. Это считается нормальной практикой? Или в будущем нужно будет это исправить? Например, засунуть его в корневой каталог ( там где находится файл settings)
Большое спасибо вам, за науку! 👍 Сегодня не поленился и применил такую же логику на одном своем проекте на Lumen (PHP), реально стало гораздо удобнее. Теперь смотрю на очищенный от бизнес логики контролер и аж глаза радуются. 😀
Помню в одних из первых видео у вас дублировалось на экран все символы которые вы печатали, для меня это было очень полезно так как я стараюсь полноценно научиться пользоваться vim'ом. Было бы очень круто если бы во всех видео с практикой было такое отображение.
Для функций которые прям ничего не возвращают есть клёвая штука в typing модуле - это NoReturn. Наверное её использование более логично в данном случае. Благодарю за видео, годный контент делаешь! Лайк
Это только для функций которые именно что не завершаются, например в которых бесконечный цикл. Если функция всё же нормально завершается и ничего не возвращает, то необходимо использовать None
@@t0digital Сразу пошел смотреть на свои проекты, и как истинный Джун, я там налажал, все как в видео ) Исправлять начал, такая красота стала а!) Даешь больше видео по Питону!)
Полезное видео! Одно замечание: выносить код, связанный с БД в отдельный файл есть ли хорошая идея? Каждая вьюшка, класс или функция, связана с роутером. Она или дает инфу из БД, либо ее ложит туда. Придется ради одной-двух строк писать ненужные функции и засовывать их, куда не найдешь потом.
Что можно сказать... Необходимо было данный урок посмотреть два года назад... Что бы сегодня небыло так больно, прийдя к осознанию того, что можно было всё это знать заранее, а не приходить к аналогичному мнению пройдя по тысячи грабель...
Много по существу, интересно услышать комментарии на такие вопросы: 1. mailchimp_services.py со временем резонно переедет в /services/mailchimp.py, где рядом будут все другие внешние апи и интеграции. Не будет путаницы этих services и services внутри app? 2. Как по мне, название add_email_to_common_mailchimp_list не говорит о том, что будет идти запись каких-то данных в базу, помимо обращения к только mailchimp. 3. _get_mailchimp_service тут вызывается каждый раз дважды, почему бы не объявить глобально клиент в начале файла и юзать его готовый? 4. Запросы к базе и обработка результатов нормально уживаются внутри app/services.py или бывает необходимость разделить это в дальнейшем тоже на 2 отдельных слоя?
1. Либо services.py, либо папка=пакет /services/ с файлами=модулями внутри. В целом не проблема обычно начать с services.py модуля и заменить его впоследствии на пакет с несколькими модулями. 2. Согласен, это не очень хорошо. Есть поведение, которое по названию функции не подразумевается. Надо переименовать и/или побить функцию на несколько (уже не помню детали по видео) 3. Глобально в начале файла я бы это не создавал, в целом можно обернуть это всё в класс и создавать в нём один экземпляр или синглтон сделать, или просто в _get_mailchimp_service реализовать кеширование созданного экземпляра. Есть куда улучшать, всего в одном видео не показать, да и улучшение процесс в общем бесконечный, если есть время на него 4. Думаю, что зависит от задачи. Что-то простое уживётся, что-то сложное точно надо будет побить на 2 или больше слоев в зависимости уже от бизнес-логики. Мыслите верно:)
Спасибо за видос. Хотелось бы ещё видос по DRF. Очень классно наблюдать за тем, как пишет профи. У меня вопрос: мы очень часто создаём mailchimp client. Можно ли его как-то вынести в singleton? Чтобы у нас был один экземпляр клиента.
Привет. Давно смотрю твои видео, спасибо за интересную информацию. Но после этого видео возникли вопросы: Почему логику инфраструктурного слоя называешь "бизнес-логикой"? Инстанцировать в каждой функции мейлчимп-сервиса новый клиент мейлчимпа кажется совсем плохой идеей. Особенно учитываю, что на верхнем уровне он инстанцируется всеравно и лучше бы его передавать из вью. Понимаю, что необходимо упрощать для лучшего восприятие у зрителей, но на мой взгляд эти "упрощения" потом аукнутся плохой архитектурой и не пониманием в целом. PS Везде уже советовали эту книгу, но ... www.ozon.ru/context/detail/id/144499396/
На самом деле, если вы прочекаете id этих инстансов, он будет одним и тем же, так работает интерпретатор Python. Ну, то есть, де-факто это будет один и тот же клиент. НО! Об этом, конечно, обязательно нужно было сказать, и, во-вторых, всё-таки не надо так делать.
у одного индуса подглядел очень крутую структуру проектов)) он создает папку apps, а в ней уже создаёт все приложения)) и тогда никогда не запутаешься что у тебя где))) вроде казалось бы мелочь, а как упорядочивается структура проектов!)) Например: myproject/ ----apps/ ----|----app_one/ ----|----app_two/ ----|----app_three/ ----myproject/ ----static/ ----templates/ ----manage.py
@@t0digital да, согласен) по сути так и есть)) но как же скрепы и соглашённости между django и flask разработчиками называть "папку с конфигами" названием проекта?)) P.S. Сейчас сижу и смотрю видос)) многое подчеркнул для себя))) спасибо))
По моему, вместо того чтобы создать функцию add_email_to_common_mailchimp_list в новом файле, можно было сделать функцию в model CommonMailingList и назвать её просто add_email
На практике в основном так и пишете? Сначала единый кусок кода реализующий задачу, а потом его рефакторинг? Или предварительно проводите анализ, чтобы сразу выделить отдельные задачи, продумываете, если необходимо, систему классов? Было бы очень интересно увидеть пример кодинга с предварительным анализом задачи и чтобы она не разбивалась так красиво на по сути один параметризуемый метод.
Правильно ли я понимаю, что вы создали фабрику которая возвращает обьект мейлчипа. Но при этом каждый раз создается новый объект, и аутентификация по кредам к апи. То есть во всех местах где мы вызываем эту фабрику мы спамим обьектами в память и дудусим сервер? Стоит ли в этой задаче делать ленивую фабрику, с синглтоном, и использовать один обьект? Спрашиваю потому что натыкаюсь на менние что синглтон это антипатерн, ну и вообще применим ли такой подход конкретно сейчас. Спасибо.
Немного смущает дублирование данных (email) в разных моделях. Кажется, начальное выделение сущностей для моделей и повлекло такой дубляж функционала кода и еще повлечет много лишней работы в будущем. Будь у нас просто: Подписчик, подписки - то этого дубляжа не получилось бы с самого начала. Или я что то упускаю. Но, это интересно. Как раз читаю гидлайн по дизайну. Спасибо!
А разве не стоит mailchimp_client создавать один раз и потом передавать в функции как аргумент вместо того, чтобы каждый раз его создавать внутри каждой функции?
А как в таком случае должна проходить валидация данных? Она же по идее должна быть в сериализаторах/формах, но при этом, если мы будем тестировать бизнес логику, то валидация данных будет и внутри "services"? Например, минимальная длина имени пользователя - 5 символов. Если с фронтэнда приходят невалидные данные, сериализатор заругается. А как быть при тестировании? Ведь когда мы тестируем бизнес логику, данные через сериализаторы не проходят)
Мегаполезно, спасибо!)) Один вопрос остался: как с базой данных правильно взаимодействие поставить в бизнес логике? Сейчас отдельный файл для этого использую, но было бы интересно посмотреть как это делаешь ты, котан))
@@t0digital Выносить ли все обращения к базе данных в отдельный файл, например: connect.py ? И в этом файле обращения к базе данных вынести в функции и обращаться к ним в остальном коде проекта?
Круто, но есть нюансы. В примере какое-то процедурное программирование, что странно. К тому же выходит что все, кто пишет джангу дураки и не придумали куда код основной логики нужно класть. А между тем во многих мануала, в том числе с том который позиционирует себя как best-practices, пишут что логика должна быть в моделях. A common pattern in MVC-style programming is to build thick/fat models and thin controllers. For Django this translates to building models with lots of small methods attached to them and views which use those methods to keep their logic as minimal as possible. There are lots of benefits to this approach.
Писать всю БЛ в джанго моделях - неправильно, смешивать структуру БД данных с БЛ - неправильно, даже если в джанго документации будет написано обратное. Это моё мнение и мнение, которого мы придерживаемся в наших проектах, никому не навязываю, пишите хоть во вьюшках как в лучших PHP домах 15 лет назад, в одной кашке HTML, JS, стили, запросы в БД и их обработка🙏
Вот круто всё, да. И понимаю, что ты декомпозируешь сначала функции, чтобы логику вынести из вьюх, потом в модели. Ситуация следующая, вот у меня есть рабочий пет-проджект, я его хочу перенести на джангу. Я джангу полистал, посмотрел, сделал их туториал, работает, хорошо. Куда мне дальше идти - читать доку джанги, чтобы перенести свой пет - проджект на джангу или как далее действовать ? Я, в принципе, примерно всё понимаю, что касается структуры проекта (вьюхи, модели, роуты) и примерно представляю как это сделать, но ка к юзать методы джанговые изнутри коробки не могу понять - каждый раз лезть в доку и искать подходящий для той или иной ситуации метод (или что-то ещё джанговое) ? Спасибо.
Автор немного слукавил, когда решил не обрабатывать ошибки из сервисов - а это немаловажный аспект. В конце вообще отчебучил, добавив в название вьюшек мейлчип - чем усилил свзянность кода с конкретным сервисом. Дублирование кода во вьюхах - это уж совсем донный случай, и то что автор убрал дублирование из надуманного случая, который можно было бы решить путем доьавления еще одноготпараметра во вьюхе, ну никак архитектурой назвать нельзя.
А это нормально что мы создаём объект mailchimp теперь не один раз, а много раз? Может лучше этот объект передавать в функцию или вообще унаследоваться от маилчимпа и описать все эти функции как методы?
Привет, хотел тебя спросить совета, прочитал книгу python для разработчиков, все примеры в книге прошел, позапускал, пересмотрел несколько курсов по python, сейчас пилю простенький сайт на django по найденному руководству в сети, и тут я себя спрашиваю какая моя цель, ответ научиться писать код на python, научит ли меня Django писать код на python или я просто научусь управлять классами Django, при это зря трачу время, или стоит все-таки бросить все силы на углубленное изучение python, а потом приступать к Django?
И еще вопрос. Почему в данном случае вы сделали два самых верхних публичных метода, вместо одного, добавив в его вызов еще пару параметров, чтобы определять ветку по которой надо обработать входные данные? Это бы усложнило логику этого метода, но сократило дублирование кода. Как научиться этому балансу, когда нужно сделать покороче, но посложнее, а когда подлиннее, но попроще? Есть книги в которых предлагаются критерии для разрешения этой диллемы или у каждого этот баланс индивидуальный и формируется самостоятельно при увеличении опыта разработки?
Привет хотел тебя спросить почему на твоём канале очень мало информации об flask ? Flask уже никто не использует в 2020 ? Или ты им редко пользуешься в своей работе?
Я считаю, что нет, если речь о джанговых моделях. Лучше к ним относиться как к структуре данных, возможно используя какие-то несложные кастомные ObjectManagers, остальное лучше писать в отдельном слое.
Мой курс «Хардкорная веб-разработка» - course.to.digital
Вжух!
Сегодня закончил проходить один неплохой курс по Django, чтобы реализовать свой петпроджект. Сел за "чистый лист" и понял, что понятия не имею, как правильно организовать архитектуру приложения с учетом обработки бизнес-логики. Почему-то этот вопрос в курсе обойден стороной (а точнее там все зафигачили во вьюху). Посмотрел твое видео - и в голове все встало на свои места. Большое спасибо, очень ценно!
Что за курс закончил? Поделись названием
@@normaneye5187 Гоша Дударь
Обычно вроде как в модели все советуют выносить, но ао вьюху, это конечно прикол
Тоже курсы прохожу, уже пошла рефакторить😂
смотри в сторону паттернов. Типа Репозитории Dry.... Когда нужно использовать и когда не нужно. Паттерны написаны кровью и пОтом разрабов, рекомендую. После изучения паттернов поймешь что джанго это то еще говно с коробки.
Диджитализируй: *выпускает видео*
Я: *ставлю лайк и иду рефакторить*
Рад, что полезно!
Каеф. Если будет не сложно, хотелось бы увидеть каноничный REST API на Django rest framework.
Спасибо :3
Спасибо! Возможно запилю:)
Тоже очень интересно
Во во точняк!!!
@@t0digital тоже бы посмотрел
Было бы очень интересно
Мне, как новичку в Django и вебе вообще, это видео просто чертовски полезно. Спасибо вам большое и удачи в развитии канала
Отлично, рад, что полезно!
Правильно нарвался на видос)) не будешь совершать наших новичковских ошибок))
Вот сейчас решил глянуть на свой старый проект, а там одна вьюшка на 285 строк кода, другая на 176)))
не надо так))
Как успехи за 3 года? Устроился?
Очень приятно посмотреть, как прямые руки код пишут. И, надеюсь, полезно
Спасибо! Тоже хочется верить, что полезно:)
Лёха - это просто бомба, спасибо тебе большое ! Формат огонь, кратко\четко\все понятно и по делу, требую продолжения )
Спасибооо!
Сразу видно, пользователя Виндоус)
В PyCharm используй Shift+F6 для переименования функций и классов. Иначе при частых переименованиях очень легко поломать код в каком-то месте, просто, потому что забыл там переименовать (и даже об этом знать не будешь). А заодно расскажи про это новичкам. Это будет очень полезный для них совет.
Вот это реально сейчас пригодилось , ибо начал переписывать старый проект и после просмотра понял , что допустил кучу ошибок даже в новой версии, спасибо , очень помогло
Отличное видео. Очень жалею, что не посмотрел его раньше, потому что мне пришлось до концепции отделения бизнес-логики доходить самому очень кровавым и долгим путем. А тут бац: и всё готовое, пользуйся на здоровье. Спасибо вам огромное за ваш труд! Однозначно лайк :).
Колокольчик уведомлений от этого канала никогда не огорчал.
Спасибо за очень полезную информацию!
Пожалуй, ты прав, поставлю-ка колокольчик
Видео отличное, из серии "ответы на вопросы, которые вы боялись спросить")) Но буду рад услышать совет - я, к сожалению, не питонист, а node.jsник, но принципы там очень схожи. Так вот:
1) У тебя бизнес логика для рассылок жестко привязана к mailchimp. А что если завтра прийдеться перейти на другой сервис рассылок? Везде рефакторить импорт и названия? Хоть я и не верю что наступит это "завтра", но в общем случае рекомендуют создавать интерфейс по типу IEmailService, и чтобы mailchimp сервис реализовывал его. Вопрос: что с этим делать, и как вы реализовываете это в питоне?
2) Могут ли сервисы импортировать другие сервисы? Ответ скорее всего да, но как в таком случае тестировать отдельные сервисы? Обычно применяют dependency injection, но можно ли без него обойтись?
Заранее спасибо.
Приветствую! Для начала хотел поблагодарить за контент и выразить свою признательность за тот вклад, который Алексей делает в сфере популяризации и развития индустрии.
Мне одному кажется, что в последнее время очень много внимания уделяется комментированию и именованию переменных, совсем позабыв о значимости методик моделирования и интерпретации кода как такового. Нет, я не говорю, что комментировать код не нужно, - нужно!!! и причем обязательно. В последнее время, лично у меня, сложилось ощущение, что все аля тимЛиды и сеньёры сговорились, пытаясь навязать мнимые ценности джунам, маскируя облегчение собственноручного код ревью, под «Паттерны комментирования».
А теперь внесу свои пару капель дегтя в бочку меда:
1. GET запросами оформлять почтовые подписки? Серьезно?
2. По сути задачи 2 представления можно было бы отменить в 1, тем самым, применение DRY выглядело бы поубедительнее. Выделяя case_id = None(общие подписки) мы можем ограничиться одной моделью и одним представлением, тем самым «развязывая себе руки» для более высокоуровневого манипулирования сущностями.
3. Django.forms на мой взгляд решает все те проблемы, которые были размазаны между views.py(валидация) и services.py(логика) … Хотя тут уже больше вопрос вкусовщины…
4. CBV… Всегда стараюсь отдать предпочтения именно им, только если не стоит вопрос производительности. Но на таких задачах только они. Как отработает представление, если запрос будет POST,PUT? Что будет, если для каждой передаваемой переменной нужно удалить пробелы? Ну и тд….
5. Settings.py Ну если мы бьемся за минимизацию количества строк в файле, то мб переменные mailcamp вынести в отдельный файл(аля mailcamp_settings.py), а в settings.py сделать импорт?
6. Настоятельно не рекомендую делать запросы к сторонним сервисам в рамках синхронного запроса. Это вешает сервис….причем как правило каскад сервисов… Но это уже другая история..
Алексей еще раз благодарю за контент!! Делать познавательные видео, гораздо полезнее и познавательнее, чем писать критикующие каменты!
Спасибо за развернутый комментарий!
> GET запросами оформлять почтовые подписки? Серьезно?
Вьюшка из видео обработает и POST запрос, но мейл в данном случае передан в GET параметре, да. Я не считаю, что жёсткое следование REST в этом конкретном примере столь важно.
> По сути задачи 2 представления можно было бы отменить в 1
Можно, но я не сказал бы, что две эти задачи настолько схожи, что имеет смысл объединить их в одну вьюшку. Подписки на разные сущности вполне подвержены потенциально разной логике обработки (как минимум будет проверка наличия Case, в будущем может появиться еще что-то, например, проверка авторов, относящихся к Case, и навешивание отдельных тегов в Mailchimp подписывающемуся). Если у нас 2 вьюшки - разный код будет в разных вьюшках, если у нас 1 вюьшка - то в ней неминуемо будут появляться куча if ветвлений, что усложнит логику, усложнит чтение и поддержку кода. Помимо DRY есть еще KISS:) Возможно я бы сделал CBV с наследованием, но опять же не уверен, что это здесь оправдано.
> Django.forms на мой взгляд решает все те проблемы
Я не считаю правильным использовать формы для чего-то, выходящего за рамки работы с формами.
> CBV… Всегда стараюсь отдать предпочтения именно им
Нормально, почему нет. Я тоже люблю CBV, как раз туда проверку исключений добавить в базовый класс и тд.
> settings.py
Можно, но выносить несколько строк кода в отдельный файл не уверен, что оправдано. Если конфигов прям много-много, тогда да. Но на практике такого не видел, чтобы конфигов в одном settings.py было столь много, чтобы это перестало быть комфортным.
> Настоятельно не рекомендую делать запросы к сторонним сервисам в рамках синхронного запроса
Да, конечно, тем более в синхронной джанге. Но это действительно другая история, не про БЛ.
Спасибо:)!
Диджитализируй! Спасибо за ответ!)
Я не придерживаюсь позиции rest, тут какбы позиция реализации http: если основной результат выполнения запроса запись в хранилище, то post исправление put и тд. Эти рекомендации были задолго до появления rest. «Нет ничего более постоянного, чем временное» и «проект нельзя закончить, это как ремонт в своей квартире: можно только остановить»
а будет тематика о тестировании?
интересно было бы послушать, unittest, pytest, best practice
всяких теорий полно, а практики совсем мало, особенно что касаемо Джанго API
Думаю, о тестировании будет материал, да!
Поддерживаю. Я тоже вкурить не могу пока как тесты писать.
Ну так будет или нет? =)
Отличный выпуск! Хорошо все рассказал и показал - красавчик! Получился неплохой пример написания кода. Причем есть даже такая практика - сначала пишем как попало (если не можем определиться с архитектурой и структурой на "берегу"), а потом рефакторим, чтобы не делать "равиолли-код" и избежать "оверинженеринга" (правда, это скорее для новичков - у опытных разработчиков почти все получается сразу).
P.S.: Но опыт не пропьешь - написать вьюшку начинающего junior-а не получилось (всеравно чувствуются хорошие привычки) ;). Я обычно не пишу комментарии, а сейчас отвлекся и вместо того, чтобы дописать сообщение к коммиту - пишу комментарий ;)
Ещё правда есть пару вопросов, не обессуть ;)
Disclaimer: цель данного комментария узнать мнения автора видео. Он не имеет задачи задеть чьи-либо религиозные чувства (в том числе в нейминге) и породить священную войну в ответах под собой. Автор комментария так же не является "троллем" и просто хочет узнать мнения автора видео.
1. Почему services, а не logic? Я понимаю, вкусовщина, но просто интересно твое мнение. У меня при виде services сразу в мыслях, что там код какого-то сервиса, а не бизнес-логика пакета. Хотя я бы положил работу с клиентом mailchamp (mailchamps_services) куда-нибудь в utils. Причем, можно даже на уровне проекта, а не приложения - так оно будет доступно для всех пакетов, если понадобится. Уж очень это похоже на шорткаты. Хотя кто-то говорит, что utils - это зло, потому что мы складываем туда все, что неможем отнести к какому-то модулю. Логику самого приложения (services.py у тебя) я бы закинул в logic.py (но тут просто различие в названии).
Вообще правильный нейминг это холиварная тема (правда тут у каждого своя - главное, чтобы было понятно), поэтому можешь не отвечать ;).
P.S.: Зря, зря я написал этот вопрос, но дюже интересно узнать твое мнение.
2. Как ты относишься к логике в django-rest-framework (DRF) фильтрах и сериализерах если речь идет не о логике сериализации/фильтрации? Ну самое элементарное это методы create/update в сериализерах DRF, вместо вызова функций логики сохранения (простой или сложной) непосредственно во view функции?
P.P.S.: Жирноватый комментарий получился, спасибо всем кто дочитал до конца и прошу прощения за потраченное время и ресур вашего зрения ;). Ещё раз повторюсь, что нехочу никого обидеть (особенно автора видео) и если так получилось, то за это тоже прошу прощения. Так же прошу прощения за переход с автором видео на "ты" без его разрешения. Но проще просить прощения, чем разрешения (Zen Python) - так что можно бросить в меня Exception ;)
И ещё раз хочу сказать спасибо за видео и за канал в целом. Для новичков (да и не только) это очень полезный формат, потому что увидеть как опытные разработчики программируют и мыслят мало где можно. Есть, конечно github, но в хороших проектах с хорошим кодом новичку будет трудно разбираться и понимать мотивацию, а здесь все доступно, понятно и с комментариями (как говорится то, чему не учат в школе и даже в университете ;)). Ещё раз спасибо - продолжай в том же духе, ты делаешь полезное дело!
Это что за такое осмысление Python Zen про "просить прощение"? :D Поделитесь источником, будьте добры.
@@trytoStopTV Здравствуйте! Вы задали очень интересный вопрос, и чтобы на него ответить я ещё раз открыл PEP 20 в поисках "Easier to ask for forgiveness than permission" и.... не нашел. Для меня это было странно, я так привык к этому принципу, который для меня казался не отделимым от Python, что начал пытаться вспомнить, где я его видел.
Через пару минут до меня дошло, когда я нашел его упоминание в "глоссарии" python - это принцип EAFP.
Рука - лицо. Стыдно. Но теперь выпавшее звено встало на свое место.
А Вам хочу сказать спасибо - теперь не буду ссылаться на Zen упоминая эту фразу (конечно, если опять не забуду, что это перевод расшифровки EAFP принципа...).
Третий или четвертый раз смотрю это видео. И только сейчас словил инсайт про хранение паролей в переменных окружения. Это же очень удобно, и не нужно париться, что конфиг с паролями улетит в репозиторий.
Прям душевно благодарю за видео 🔥🔥🔥🔥🔥
Отлично:)!
Отличный выпуск! Как впрочем и всегда)
Очень правильный подход показать как сделать плохо и поэтапно указать на ошибки и способы их исправить, соответственно и рефакторинг кода.
Ещё раз подчеркивает важность не торопиться и не забивать так же на проектирование и продумывание логики, а не кидаться сразу в код и что-то писать...
В общем, выпуск супер!
Я интуитивно пришёл к тому же, только осмыслить был не в состоянии. Казалось, что я просто отсебятину делаю и просто плохо усвоил джангу. А оказалось, все правильно. Респект. Все понятно. Термин services возьму на вооружение
Здравствуйте, спасибо большое за видео ролик, вы очень хорошо объяснили как правильно делать и мне как новичок в Back-end разработке очень было понятно и полезно, ещё раз спасибо 🙏
Как сказал один известный человек. Круто да этож круто. Получил для себя новый глоток для размышлений над улучшением своего проекта)
Спасибо вам огромное за полезные ролики. Недавно начал вас смотреть(являюсь junior full-stack developer-ом). Написал свой интернет-магазин, но после просмотра последних 2х видео про бизнес-логику, осознал, насколько неправильно подошел к данному вопросу(тупо копировал код из одной вьюшки в другую). Открываете глаза на программирование в целом. Спасибо огромное! C нетерпением жду выпуска следующих видосов:)
Приятно смотреть на человека, который понимает что он делает и хорошо владеет инструментом(языком программирования). Пишу на .net, но код читался, как песня.
Сколько полезной информации на вашем канале я получил не сосчитать, а сколько еще осталось). Спасибо за труд, все стало на свои места после вашего наглядного примера. Всех благ!🔥
Отлично, рад, что полезно!
Не подскажешь? А файл mailchimp_services не нарушает принцип независимости приложений? Написан в одном приложении, другое его импортирует. Это считается нормальной практикой? Или в будущем нужно будет это исправить? Например, засунуть его в корневой каталог ( там где находится файл settings)
Спасибо огромное. Новые проекты делаю с файлом services в app'ах.
Было бы интересно посмотреть review какого-нибудь opensource проекта на django
Интересная идея, спасибо!
Большое спасибо вам, за науку! 👍
Сегодня не поленился и применил такую же логику на одном своем проекте на Lumen (PHP), реально стало гораздо удобнее. Теперь смотрю на очищенный от бизнес логики контролер и аж глаза радуются. 😀
Отлично! Всё правильно, применимо на любой технологии:)
Отлично! Помогло разрешить ряд вопросов, которые бродили в голове.
Супер! Ну как всегда собственно))) спасибо большое за твой труд!
Круто! Очень полезно, прям больше понимания стало! Хоть только начинаю Django мучить, но теперь есть понимание как реализовывать проекты!
Помню в одних из первых видео у вас дублировалось на экран все символы которые вы печатали, для меня это было очень полезно так как я стараюсь полноценно научиться пользоваться vim'ом. Было бы очень круто если бы во всех видео с практикой было такое отображение.
Привез лайкосиков, куда разгружать, командир? =)
О, разгружаем здесь!
Алексей, спасибо! Это как раз то, что мне было нужно
Спасибо большое, очень полезное видео.
Вот видос который меняет взгляд на жизнь:)
Да. Пожалуй нужно подписаться и поставить лайк. А ведь он говорил вам, не используйте time.time, еще тогда надо было задуматься.
Отличный ролик и отличный канал! Респект. Работаю бэкендером на Django, и ваши ролики помогают развиваться. Спасибо
Спасибо! Рад, что полезно
Для функций которые прям ничего не возвращают есть клёвая штука в typing модуле - это NoReturn. Наверное её использование более логично в данном случае. Благодарю за видео, годный контент делаешь! Лайк
Это только для функций которые именно что не завершаются, например в которых бесконечный цикл. Если функция всё же нормально завершается и ничего не возвращает, то необходимо использовать None
Огромное спасибо за контент!
В принципе ничего нового я тут увидеть не ожидал, но какое же черт возьми удовольствие приносит лицезрение распиливания лапши)
Офигенный мастер-класс. Спасибо.
Полезность канала растет на глазах! Живой кодинг - это маст хэв)
Йеее:) Спасибо!
Самое полезное видео по Джанге. Thx
Алексей, просто СПАСИБО тебе! Лучший канал по питону.
Спасибооо!
Ну здесь мои полномочия всё...Здесь питоний дух, Питоном пахнет )))
Хахах:) Полномочия всё!
Супер. Обожаю ваши труды)) респект
Вот это как раз мега-полезный выпуск, очень в тему к тому, что я сейчас делаю
Отлично, рад, что полезно
Отличное видео, просмотрел все. Вынес много интересного.
Рад, что полезно!
@@t0digital Сразу пошел смотреть на свои проекты, и как истинный Джун, я там налажал, все как в видео ) Исправлять начал, такая красота стала а!) Даешь больше видео по Питону!)
Спасибо за урок сансей) пойду заварю чай и отрефакторю свой код полностью)
Спасибо, интересно и познавательно!
Офигеть, ты все таки его сделал))
Спасибо большое, гляну обязательно)
Лайк не глядя)
Юхууу, спасибо!
Отлично! Можно и нужно всё-таки исследовать exceptions и что-то с ними делать. Не все всегда будет работать гладко думаю
Да, по исключениям были недавно видео на канале, и по их обработке в middleware джанги
@@t0digital Посмотрю, спасибо
Вот где вим брал свое начало)
Отличное объяснение!
Спасибо!
Отличный выпуск, как всегда огромное Спасибо! Было бы неплохо еще посмотреть про логирование, как неотъемлемое составляющее проекта в продакшн.
Будет такое видео
@@t0digital Очень хорошо, буду ждать!
Мне понравилось - очень полезная информация
Спасибо!
Можно было бы сократить видео до слов "Надо создавать функции и выводить их в отдельный файл"
Могу сократить еще сильнее: надо
Полезное видео!
Одно замечание: выносить код, связанный с БД в отдельный файл есть ли хорошая идея?
Каждая вьюшка, класс или функция, связана с роутером. Она или дает инфу из БД, либо ее ложит туда. Придется ради одной-двух строк писать ненужные функции и засовывать их, куда не найдешь потом.
Как насчет устранения жестких зависимостей от баз данных и самого Джанго? В стиле Чистой архитектуры. Вот это было бы интересно.
Что можно сказать... Необходимо было данный урок посмотреть два года назад... Что бы сегодня небыло так больно, прийдя к осознанию того, что можно было всё это знать заранее, а не приходить к аналогичному мнению пройдя по тысячи грабель...
Много по существу, интересно услышать комментарии на такие вопросы:
1. mailchimp_services.py со временем резонно переедет в /services/mailchimp.py, где рядом будут все другие внешние апи и интеграции. Не будет путаницы этих services и services внутри app?
2. Как по мне, название add_email_to_common_mailchimp_list не говорит о том, что будет идти запись каких-то данных в базу, помимо обращения к только mailchimp.
3. _get_mailchimp_service тут вызывается каждый раз дважды, почему бы не объявить глобально клиент в начале файла и юзать его готовый?
4. Запросы к базе и обработка результатов нормально уживаются внутри app/services.py или бывает необходимость разделить это в дальнейшем тоже на 2 отдельных слоя?
1. Либо services.py, либо папка=пакет /services/ с файлами=модулями внутри. В целом не проблема обычно начать с services.py модуля и заменить его впоследствии на пакет с несколькими модулями.
2. Согласен, это не очень хорошо. Есть поведение, которое по названию функции не подразумевается. Надо переименовать и/или побить функцию на несколько (уже не помню детали по видео)
3. Глобально в начале файла я бы это не создавал, в целом можно обернуть это всё в класс и создавать в нём один экземпляр или синглтон сделать, или просто в _get_mailchimp_service реализовать кеширование созданного экземпляра. Есть куда улучшать, всего в одном видео не показать, да и улучшение процесс в общем бесконечный, если есть время на него
4. Думаю, что зависит от задачи. Что-то простое уживётся, что-то сложное точно надо будет побить на 2 или больше слоев в зависимости уже от бизнес-логики.
Мыслите верно:)
Долгожданное видео ))))
Йееее!
Спасибо за видос. Хотелось бы ещё видос по DRF. Очень классно наблюдать за тем, как пишет профи. У меня вопрос: мы очень часто создаём mailchimp client. Можно ли его как-то вынести в singleton? Чтобы у нас был один экземпляр клиента.
Здравствуйте, расскажите пожалуйста про вашу настройку ide (понравилась подсветка django файлов в левом сайдбаре)
Здравствуйте, Алексей!)
А не думали ли вы о выпуске обновления данного видео, с новыми технологиями, и тд
Топ контент по джанго
Спасибо!
Очень классное видео!
Спасибооо!
Больше годных практик богу годных практик)
Привет. Давно смотрю твои видео, спасибо за интересную информацию.
Но после этого видео возникли вопросы:
Почему логику инфраструктурного слоя называешь "бизнес-логикой"?
Инстанцировать в каждой функции мейлчимп-сервиса новый клиент мейлчимпа кажется совсем плохой идеей. Особенно учитываю, что на верхнем уровне он инстанцируется всеравно и лучше бы его передавать из вью.
Понимаю, что необходимо упрощать для лучшего восприятие у зрителей, но на мой взгляд эти "упрощения" потом аукнутся плохой архитектурой и не пониманием в целом.
PS Везде уже советовали эту книгу, но ... www.ozon.ru/context/detail/id/144499396/
Тоже хотел оставить коммент об этом. Но видео все же годное для начинающих
На самом деле, если вы прочекаете id этих инстансов, он будет одним и тем же, так работает интерпретатор Python. Ну, то есть, де-факто это будет один и тот же клиент. НО! Об этом, конечно, обязательно нужно было сказать, и, во-вторых, всё-таки не надо так делать.
В классах используются миксины для создания данных в бд из форм например, это помути обработку бизнес логики мы делегируем классу миксину?
у одного индуса подглядел очень крутую структуру проектов))
он создает папку apps, а в ней уже создаёт все приложения)) и тогда никогда не запутаешься что у тебя где))) вроде казалось бы мелочь, а как упорядочивается структура проектов!))
Например:
myproject/
----apps/
----|----app_one/
----|----app_two/
----|----app_three/
----myproject/
----static/
----templates/
----manage.py
Да, неплохо. Мне только нравится myproject переименовывать в config, потому что там по сути конфиги внутри
@@t0digital да, согласен) по сути так и есть)) но как же скрепы и соглашённости между django и flask разработчиками называть "папку с конфигами" названием проекта?))
P.S. Сейчас сижу и смотрю видос)) многое подчеркнул для себя))) спасибо))
Отлично рассказываешь! Кратко, ясно и по делу. Не планируешь ли серию уроков по Django?
Я пишу сейчас большой курс по веб-разработке на Python, он будет
@@t0digital Балдеееж. Аж настроение поднялось хы
@@t0digital курс будет платным?
Диджитализируй! Привет! А в нем будет DRF и какой-нить JS фреймворк?
курс будет платным
20 июл. 2020 г. сразу лайк
По моему, вместо того чтобы создать функцию add_email_to_common_mailchimp_list в новом файле, можно было сделать функцию в model CommonMailingList и назвать её просто add_email
Отличное видео
Спасибо!
Спасибо большое за видос, было очень полезно. Не нашел у вас похожего видео про DRF. Его нет?
его нет
А как сделать этот mailchimp асинхронными?
На практике в основном так и пишете? Сначала единый кусок кода реализующий задачу, а потом его рефакторинг? Или предварительно проводите анализ, чтобы сразу выделить отдельные задачи, продумываете, если необходимо, систему классов? Было бы очень интересно увидеть пример кодинга с предварительным анализом задачи и чтобы она не разбивалась так красиво на по сути один параметризуемый метод.
Есть несколько стримов с живой разработкой телеграм бота на канале, этого 2023го года
Спасибо за столь быстрый ответ! Поставлю в очередь на просмотр.
Правильно ли я понимаю, что вы создали фабрику которая возвращает обьект мейлчипа. Но при этом каждый раз создается новый объект, и аутентификация по кредам к апи.
То есть во всех местах где мы вызываем эту фабрику мы спамим обьектами в память и дудусим сервер?
Стоит ли в этой задаче делать ленивую фабрику, с синглтоном, и использовать один обьект?
Спрашиваю потому что натыкаюсь на менние что синглтон это антипатерн, ну и вообще применим ли такой подход конкретно сейчас. Спасибо.
Fantstic !
Немного смущает дублирование данных (email) в разных моделях. Кажется, начальное выделение сущностей для моделей и повлекло такой дубляж функционала кода и еще повлечет много лишней работы в будущем. Будь у нас просто: Подписчик, подписки - то этого дубляжа не получилось бы с самого начала. Или я что то упускаю. Но, это интересно. Как раз читаю гидлайн по дизайну. Спасибо!
А разве не стоит mailchimp_client создавать один раз и потом передавать в функции как аргумент вместо того, чтобы каждый раз его создавать внутри каждой функции?
Добрый день, будет ли курс по FastApi?
А что насчёт class-based views?
А как в таком случае должна проходить валидация данных? Она же по идее должна быть в сериализаторах/формах, но при этом, если мы будем тестировать бизнес логику, то валидация данных будет и внутри "services"? Например, минимальная длина имени пользователя - 5 символов. Если с фронтэнда приходят невалидные данные, сериализатор заругается. А как быть при тестировании? Ведь когда мы тестируем бизнес логику, данные через сериализаторы не проходят)
Мегаполезно, спасибо!))
Один вопрос остался: как с базой данных правильно взаимодействие поставить в бизнес логике? Сейчас отдельный файл для этого использую, но было бы интересно посмотреть как это делаешь ты, котан))
Не очень понял вопрос
@@t0digital Выносить ли все обращения к базе данных в отдельный файл, например: connect.py ?
И в этом файле обращения к базе данных вынести в функции и обращаться к ним в остальном коде проекта?
Жаль, что не в виме :)
Круто, но есть нюансы. В примере какое-то процедурное программирование, что странно. К тому же выходит что все, кто пишет джангу дураки и не придумали куда код основной логики нужно класть. А между тем во многих мануала, в том числе с том который позиционирует себя как best-practices, пишут что логика должна быть в моделях.
A common pattern in MVC-style programming is to build thick/fat models and thin controllers. For Django this translates to building models with lots of small methods attached to them and views which use those methods to keep their logic as minimal as possible. There are lots of benefits to this approach.
Писать всю БЛ в джанго моделях - неправильно, смешивать структуру БД данных с БЛ - неправильно, даже если в джанго документации будет написано обратное. Это моё мнение и мнение, которого мы придерживаемся в наших проектах, никому не навязываю, пишите хоть во вьюшках как в лучших PHP домах 15 лет назад, в одной кашке HTML, JS, стили, запросы в БД и их обработка🙏
Вот круто всё, да. И понимаю, что ты декомпозируешь сначала функции, чтобы логику вынести из вьюх, потом в модели.
Ситуация следующая, вот у меня есть рабочий пет-проджект, я его хочу перенести на джангу.
Я джангу полистал, посмотрел, сделал их туториал, работает, хорошо.
Куда мне дальше идти - читать доку джанги, чтобы перенести свой пет - проджект на джангу или как далее действовать ?
Я, в принципе, примерно всё понимаю, что касается структуры проекта (вьюхи, модели, роуты) и примерно представляю как это сделать, но ка к юзать методы джанговые изнутри коробки не могу понять - каждый раз лезть в доку и искать подходящий для той или иной ситуации метод (или что-то ещё джанговое) ?
Спасибо.
Автор немного слукавил, когда решил не обрабатывать ошибки из сервисов - а это немаловажный аспект. В конце вообще отчебучил, добавив в название вьюшек мейлчип - чем усилил свзянность кода с конкретным сервисом. Дублирование кода во вьюхах - это уж совсем донный случай, и то что автор убрал дублирование из надуманного случая, который можно было бы решить путем доьавления еще одноготпараметра во вьюхе, ну никак архитектурой назвать нельзя.
А это нормально что мы создаём объект mailchimp теперь не один раз, а много раз? Может лучше этот объект передавать в функцию или вообще унаследоваться от маилчимпа и описать все эти функции как методы?
Урааааааааааа!!!!!
Интересно, а сколько будет стоить сделать такой сайт?
А можно ссылку на гит, где этот код представлен. Заранее спасибо
Не выкладывал его
Привет, хотел тебя спросить совета, прочитал книгу python для разработчиков, все примеры в книге прошел, позапускал, пересмотрел несколько курсов по python, сейчас пилю простенький сайт на django по найденному руководству в сети, и тут я себя спрашиваю какая моя цель, ответ научиться писать код на python, научит ли меня Django писать код на python или я просто научусь управлять классами Django, при это зря трачу время, или стоит все-таки бросить все силы на углубленное изучение python, а потом приступать к Django?
Все круто, полезно. Только как тестировать ф-ии, использующие mailchimp? Фейковую апи mailchimp подсовывать или как?
Dima K4 тут только манкипатч поможет
Моки
Как и где можно пройти курс?
На курсе есть проекты?
course01.to.digital в декабре выйдет новая версия курса
Запили, пожалуйста, такое по Flask
Там в целом все аналогично. Замените вьюшку джанги на вьюшку фласка и все остальное будет актуально и для фласка.
И еще вопрос. Почему в данном случае вы сделали два самых верхних публичных метода, вместо одного, добавив в его вызов еще пару параметров, чтобы определять ветку по которой надо обработать входные данные? Это бы усложнило логику этого метода, но сократило дублирование кода. Как научиться этому балансу, когда нужно сделать покороче, но посложнее, а когда подлиннее, но попроще? Есть книги в которых предлагаются критерии для разрешения этой диллемы или у каждого этот баланс индивидуальный и формируется самостоятельно при увеличении опыта разработки?
Привет хотел тебя спросить почему на твоём канале очень мало информации об flask ? Flask уже никто не использует в 2020 ? Или ты им редко пользуешься в своей работе?
Привет! В работе ни разу не пользовался, все проекты на джанге
Отличное видео, как ты считаешь нормальная ли практика хранить бизнес логику в моделях?
Я считаю, что нет, если речь о джанговых моделях. Лучше к ним относиться как к структуре данных, возможно используя какие-то несложные кастомные ObjectManagers, остальное лучше писать в отдельном слое.