Архитектура ПО, MVC и бизнес-логика. Критика Django
Вставка
- Опубліковано 18 січ 2020
- Мой курс «Хардкорная веб-разработка» - course.to.digital
Книжный клуб Ботаним!, где мы читаем хорошие ИТ-книги: botanim.to.digital/
Telegram: t0digital.t.me
Сказать спасибо за это видео можно здесь - boosty.to/digitalize.team
Все давно уже знают, что такое MVC и согласны с тем, что это хорошо. Но откуда тогда берутся эти проекты с километровым кодом в контроллерах, да ещё и напрямую изменяющим БД? Почему это плохо и как должно быть, а также о главной боли Django - в этом выпуске.
---
Друзья, я, автор канала, основатель и директор Salesbeat, это крутой модуль доставки для интернет-магазинов. В декабре 2019 Salesbeat вошел в состав участников акселератора Яндекс и агентства инноваций Москвы. За ближайшие 2 месяца нам надо плотно поработать и вырастить выручку проекта в несколько раз. Буду вам КРАЙНЕ БЛАГОДАРЕН за поддержку. Пожалуйста, порекомендуйте наш модуль доставки вашим знакомым с интернет-магазином, напишите о нас в своих соц сетях со ссылкой на salesbeat.pro, это очень нам поможет. Salesbeat - однозначно лучшее решение для интеграции служб доставки в интернет-магазин. СПАСИБО!
---
О правилах нейминга в коде - • Именование переменных,...
Чем так крут Python - • Чем так крут Python - ...
Поднимаем Debian сервер для Python/Django, установка и настройка с нуля - • Поднимаем Debian серве...
/****************** about ******************/
Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:
- Диджитализируй digitalize.team, разрабатываем сложные IT системы для бизнеса;
- Salesbeat salesbeat.pro, комплексный модуль доставки для интернет магазинов.
Если у вас есть проект на разработку, пишите нам на hi@digitalize.team.
С другими предложениями, а также если вам нужна одна или несколько индивидуальных консультаций/уроков по разработке (3000 руб/час), пишите мне на alexey@salesbeat.pro.
Telegram канал - t.me/t0digital
ВК - digitalize.team
RuTube - rutube.ru/channel/24802975/ab...
Дзен - dzen.ru/id/6235d32cb64df01e6e...
![Бото*бы, говнокод и профессионализм - разбираем критику [18+]](/img/n.gif)
Какой же душевный у тебя контент. Как будто с корешем на кухне болтаю. Мне лично очень заходит такой подход, удачи в развитии канала!
Спасибо, очень приятно!
Тут сложно не согласиться)
Тема супер. После первого знакомства с джангой я как то неделю пытался найти в интернете куда же нужно пихать бизнес логику. Так и не нашёл кстати) Но пришёл к тому же способу как в видео
@@Nastya99_99 отлично! Странно, что Django не даёт нормальных рекомендаций в своей же доке
@@t0digital Да, отдельный респект за это, никогда так не было приятно слушать материал
Такого понятного объяснения MVC я ещё нигде не встречал
Уже 4 раз пересматриваю и возвращаюсь к этому видео, 20 минут концентрированной, крутой информации! Спасибо!
Спасибо за подробное объяснение! Все объяснения, которые я встречал до этого, были настолько абстрактными, что больше путался чем понимал
Спасибо, лайк. Жду новых видео про архитектуру и паттерны
Лайк, на 1000% согласен! И про нейминг и про вопрос - где писать бизнес логику в Django
Давно сам задумывался о данном вопросе в Django. Сколько раз этот момент обсуждали с коллегами. Мы всю бизнес-логику выносим в фасады.
Очень полезно!
Был бы тех диром, заставил бы всех джанговодов посмотреть этот ролик.
Спасибо
Спасибо, очень доступно объясняешь, кажется я начал кое что понимать)
Отлично, рад, что полезно!
Отличная информация и ее подача, все доступно и наглядно. Большое спасибо!
Спасибо, рад, что полезно!
Отличное видео! Очень полезно и информативно. Теория ясна, теперь ждём видео с практикой модель-вью-контроллер. Не хватает таких видео, где всё архитектурно грамотно и красиво, чтобы понимать как оно происходит.
Обязательно будет живой пример. Спасибо!
Диджитализируй! АйТи студия а ещё если можно, расскажите как можно использовать одно приложение Джанго (не проект) в нескольких проектах, если такое вообще возможно. Как наоборот сделать (один проект, много приложений) понятно :)
Здравствуйте. Отличное видео. Слушать вас можно часами. Сам я работаю с Ruby и RoR. Недавно заинтересовался в джанге и сейчас уже делаю проекты и на RoR и на Джанге. Я был удивлен когда узнал, что в Джанге MVT архитектура. Действительно из-за этого код пишется то в view, то в моделях. Возможно изначально Джанга задумывалась не только как веб фреймворк. Поэтому здесь нет такого жёсткого разделения. В каждом проекте ты можешь тонко настроить всё под свои нужды. В рельсах хоть и MVC, но бизнес логику ты тоже пишешь в сервисах.
Хотелось бы увидеть с вашей точки зрения топ проектов на Джанге на гитхабе с хорошим кодом. Спасибо.
Спасибо, хорошо, что у тебя посмотрел, чтобы как говорится, сразу правильно делать, а не переучиваться потом )
Так бы и сидел все время и слушал ваше объяснение. Очень интересно объясняете. Спасибо!
Спасибооо!
Большое спасибо за видео. Было очень интересно и с именованием и хранением в services было ново и полезно.
Отлично! Рад, что полезно
Единственный канал, где меня с экрана называли "Котаном". раньше......
Да, хороший был канал 😊
Да, что с котанами?
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер - таким образом, что модификация каждого компонента может осуществляться независимо
Спасибо! Очень круто
На самом деле стало понятно, как MVC укладывается в django ) а то поназывали там views это контроллер... бр, спасибо, что разъяснили!
БлагоДарю за такую замечательную подачу материала. Хотелось бы в роликах увидеть подробности, как правильно организовывать архитектуру кода при написании простого приложения (или отдельной функции бизнес-логики) соблюдая принципы DRY.
покажу как-нибудь в живом примере, да!
Как раз вовремя. Начал проект на джанго и мучался вопросом куда бизнес логику писать. Как раз начитался противоречивых советов, что во вьюху/модель писать. Потом посоветовали вообще рест фреймворк. Взрыв мозга.
А тут всё по делу и понятно, спасибо.
Отлично!
Кстати, давно уже задавался вопросом, где же в джанге бизнес прикручивать. Теперь знаю. Как раз вовремя видео подошло! Спасибо!
Отлично!
На восьмой минуте понял, что ничего не понятно, но, очень интересно. В любом случае, спасибо, Котан!
Спасибо за видео! Очень доходчиво.
Спасибо! Ещё раз упорядоченно об этом услышал
Спасибо, только учусь, инфа важная)
Хоспади, как же круто вы рассказываете!!! Спасибо!!
Спасибо!
Спасибо за четкое, понятное объяснение. Молодца
Класс! Наконец-то это ктото объяснил. Вы - спасение
Спасибо за актуальное видео!))
Как раз делаю проект на джанге.
models.py - это модели Django, отображающие структуру БД
@@t0digital еще несколько раз пересмотрел, чтоб понять mvc что такое и как в джанго это реализовано))
Спасибо, очень полезно!
ОЧЕ круто, ну вот теперь то наконец-то дошло (надеюсь)).
Отлично
Отличный канал! Суперская подача материала! Высокий уровень! Автору -- респект, котанам -- привет!
Спасибооо💪!
Респектую ребята!!! Отличное объяснение!
Спасибо!
Январь 2023 года. И Вы открыли мне глаза) спасибо Вам!)
upd: И действительно очень ламповые и приятные выпуски.
Спасибо, отличная тема!!!)
Если подытожить, в джанго советуешь делать:
1.модуль service - файлы (скрипты) с бизнес логикой (запросы к бд и другие работы с данными)
2. views.py - контроллер
3. Ну и шаблоны это понятно отображение (views из mvc)
Так?)
Да, и models.py это ORM классы и возможно совсем чуть-чуть бизнес логики
Спасибо! Настолько все очевидно и логично, что даже странно, что кто то делает иначе!!!
странно, но факт:)
Вообще сами разработчики Джанго говорят что контроллеры в Джанго это скорей urls.py а бизнес логику рекомендуют писать в models.py. В компании которой я работаю сейчас, мы тоже используем подход с services & selectors(места для агрегации данных) и мы это унаследовали от Болгарский компании hacksoftware которая одна из первых описала стайлгайд для такого стиля архитектуры для Джанго;) и это подход достаточно удобен на практике)
Very Спасибо )) очень полезно
Рад, что полезно, спасибо!
И тут все круто! Спасибо, кодер, от Котана ))))
Спасибо 🙏
Django как и DRF и генерируемая адмика Django, прямо кричит, что все процессы должны происходить вокруг модели данных.
Т.е структура models должна повторять то, что после будет выводиться в templates или пересылаться по api. Т.е Data driven design. На этом и построена вся Django. Мы создаем модели, чтобы они более-менее накладывались на реляционную модель. С помощью ModelForm мы валидируем сохраняем данные в эту модель. Выдергиваем во view использую GenericViewSet, где с минимальными усилиями это дело достаем из базы и выводим. Из-за того, что у нас все крутится вокруг models, мы получаем генерируемую админку. Все drf это только подтверждает. Он жестко завязан на работу с моделями.
Здесь нет места какой-то бизнес логике. Логики, как таковой, здесь вообще должно быть минимум. Мы просто отображаем данные из базы, вставляя на свои места в шаблоне или выводим в json. Поэтому и логику пишут ближе к выводу или данным.
Ок, давайте вынесем бизнес логику в отдельное место. Что получаем, директорию с файлами, которая набита кучей жестко связанного кода, сильно завязанного на orm, модели, формы и т.п django. По сути всю логику сгребаем в кучу. Хорошо ли это, да нет, это ужасно!
Почему-то многие думают, что если закинуть весь код в директорию services, то сразу будет хорошо. Нет, не будет.
Если начать думать о архитектуре, то станет ясно, что нужно отделить всю логику от django. От джанго останется только orm, models, views и все. Забудьте про админку, forms и все такое.
Views только работает как controller, orm вовсе изолируем за интерфейсом. Никакого Product.objects.all() из бизнес логики. Все обращение с бизнес логикой строим по средствам DTO и вызовов методов интерфейса persistent. Внутри бизнес логики уже строим нужное Entity, Services, Use Cases и т.п.
Но на это не пойдут большинство тех, кто пишет с исп. этого фреймворка, т.к оставь в нем только orm и views, станет ясно, что и сама django уже не особо то и нужна, можно Flask и Sqlalchemy или т.п, все тоже будет.
Я считаю, что нет большого смысла как-то сильно внедрять в Django какую-то выраженную архитектуру, вроде DDD или разновидность Чистой архитектуры или даже EDD, SOA и т.п.
У Django своя хорошая ниша, не сложные проекты, который строятся вокруг БД. На ней очень удобно такое реализовывать. Там все для этого. Хотя лет 5 назад, я бы с пеной у рта доказывал обратное.)))
Те, кто в силах построить сложный проект, у кого есть обширные знания архитектур их особенностей и опыт ведение я внедрения, вряд ли выберут Django. Это не его ниша.
Для сложных проектов, с большим набором логики и т.п, скорее всего будет исп. другой стек, C#, Java и т.п. Языки с которые предоставляют строгость в исп. подходах. Нормальные абстрактные классы, интерфейсы, проверка типов. То, где можно в полной мере исп. все принципы SOLID и т.п. Это дает больше гарантий, что проект будет поддерживаемый.
Тут стоит заметит, что я не говорю, что Python не подходит для больших проектов, подходит, но только как какая-то их часть, какой-то отдельный сервис, то, в чем Python действительно хорош. Но будет ли в этом отдельном сервисе Django, скорее всего нет.
Как раз в универе недавно проходили MVC, суть та же. Спасибо, что разобрали, так понятней стало
Отлично!
У вас в универе проходят мвс? А это где?
Как же вовремя это видео, когда пошел на курс по джанго... Очень хочется делать красиво. Хотелось бы подробнее с технической части, взглянуть на структуру проекта. Плохо понятно со скриншота, ну папочки там какие-то, и что?
django-service-objects юзать стоит?
В дзене питона вон говорят, что проще - лучше и вообще главное, чтоб работало.
Не все наслышаны о MVC (тем более очевидно, раз в каждом 1ом проекте такие косяки), стоит развить эту тему! Помог начать задавать правильные вопросы, спасибо!=)
ua-cam.com/video/yG3ZdxBb1oo/v-deo.html
многое поясняет данная лекция.
Отличная лекция получилась, спасибо.
Спасибо!
Спасибо!
Спасибо!!! Лайк
Спасибо за видео! Хотелось бы увидеть пример, где "плохо", а где "хорошо"
Посмотрите код ревью, несколько видео есть на канале
Более того, должен быть слой контроллера, слой сервиса, слой репозитория, слой респонс-сервиса, и каждый друг для друга есть «чёрный ящик». Работаю по такой архитектуре со Spring и JavaEE (Jakarta EE), и все великолепно поддерживается. Однако, наговнокодить можно умудриться везде, если к тому душа лежит )
Расскажи, пожалуйста, в отдельном видосе как ты проектируешь структуру классов, как описываешь интерфейсы и т.д.
Сделай пожалуйста видос про выбор лицензии проекта при создании репозитори на гитхабе. в чём между ними различия и какую для какого проекта лучше выбрать.
Привет! Спасибо за ролик!
Можешь выкинуть пример кода который "плох" и который "хорош"?
Я думаю есть примеры на гитхабе.
Потому что не совсем понятно данное разделение.
Во всяком случае для меня.
посмотрю что-нибудь, может на живом примере разберем
@@t0digital Отлично.
@@t0digital Да, было супер!
@@t0digital Спасибо огромное за видео, реально топчик. Если есть пример правильной архитектуры на Django(имеется в виду на гите мб видел) кинь пж. Сейчас работаю над проектом где django, много apps, и все сделанно во views,еще и celery, который делает одно и то же. Хотелось бы узнать как правильно делать и как исправлять это. Потому что дебажить это ад. Еще раз спасибо за видео. Если проигноришь - НЕ обижусь: все мы люди и времени на каждого у тебя нет)))
@@dvornikxilosof799 думаю, сделаем приложеньку на джанге и там все покажу
Здравствуйте спасибо за разъяснение!Подскажите пожалуйста есть пример кода на джанго которое можно посмотреть )
Мне понравилось решение в фреймворке fastAPI, там например вынесли бизнес-логику в отдельный модуль, в доке у них CRUD так выделили. Конечно добавляется ещё один слой, но выглядит масштабируемо и упорядоченно.
В джанге, почему-то, в доке такого не показывают.
В отображении не должно быть логики - да, обычно когда такое говорят, имеют ввиду именно бизнес логику :) Это такое сокращение, которое обычно воспринимается как очевидное.
Контроллер плохо называть клеем между (моделями) бизнес логикой и представлениями (отображением). У контроллера есть одна основная задача - обработать запрос. То есть ему надо принять решение о том, что хочет пользователь, выполнить нужные действия, и показать пользователю ответ. Иначе, если бы контроллер был клеем между моделями и представлениями, то по данному шаблону было бы запрещено отправлять модели с данными в представления, а нужно было бы их разбирать на массивы и отправлять только массивы.
В контроллере запрещена работа с БД через ORM? :) То есть если пользователь запросил у сайта данные о своих покупках за последний месяц, то я не могу выполнить Order::find()->andWhere(список_условий)->all(), и мне надо это куда-то в статический метод моделей совать? Это неверное утверждение, я считаю... нет ничего плохого в том, чтобы контроллер запросил данные откуда ему угодно, главное, чтобы он эти данные сам не генерировал (не считал). Как я говорил, его задача в том, чтобы понять запрос, выполнить его, и отобразить необходимые данные (а идея о том, что там не должно быть запросов в БД скорее всего родилась из утверждения, что контроллер - это всего лишь клей без какой либо собственной функции).
Насчёт записи данных - ну контроллер вполне может принять формы с данными, запустить в них процесс валидации, если он прошёл успешно, то рассовать данные по моделям и вызвать метод сохранения моделей. Под сохранением айфонов в БД это имелось ввиду? :) Если да, то в этом нет ничего преступного, потому что это всё ещё исключительно обработка запроса, и если тело запроса вдруг надо будет изменить для другого приложения, то и обработка этого запроса будет другой, а значит нам в любом случае именно эта логика будет мало полезна :)
"не предлагает места, где писать бизнес логику" - эм :)) бизнес логику надо писать в моделях (yii, yii2 тоже не предлагают никаких других мест для неё), потому что именно там ей и место. Предполагается, что модель - это самый типичный объект парадигмы ООП, то есть сущность, которая соответствует объекту реального мира и имеет свои свойства и методы для работы с ним. Потому да, логику пишем исключительно на уровне моделей и именно в них самих. Если же нам нужна абстракция не настолько большая, как "модуль", но и не настолько детальная, как "модель", то для этого паттерн MVC можно расширить такой штукой как "Service layer" (паттерн такой), когда контроллер, обрабатывая запросы, дёргает не методы моделей, а вызывает функции сервисов, которые в свою очередь уже дёргают методы моделей. (АХАХА.... пишу сообщение во время просмотра видео, снимаю с паузы, а тут "для этого создаём свой слой Бизнес логики, называем его services"... ну вот тут согласен полностью xD только это не джавовая фишка такая, а полноценный паттерн)
P.S. Судя по тому, что говорится в видео, у автора не совсем верное представление о том, что такое бизнес логика. :) Бизнес логика - это то, что с точки зрения пользователя происходит за кулисами (то, о чём он не просил, но что произошло в силу необходимости для бизнеса), при этом так, как контроллер лишь обрабатывает запрос, мы можем себе представить, что вместо него мы и посадили очень умного пользователя. Вот он решил купить телефон, что он сделает, если он умный?
- Попросит "покажи мне список всех телефонов с ценой от 10к до 20к рублей"
- Сохрани пожалуйста мой заказ и покажи что мне надо сделать, чтобы его получить (например оплатить, выбрать дату доставки и т.д.)
- Сохрани [вот эти] дополнительные данные по заказу и отправь меня оплачивать заказ
- Скажи всё ли ты правильно принял, когда и на каких условиях ждать мой заказ
Вот всё это - это то, с чем контроллер обращается к уровню моделей :) И это не является бизнес логикой, а вот всё остальное, что делает система (например расчёт скидок, отправка писем, передача заявок в разные CRM системы и т.д.) - это уже бизнес логика.
Nikolay Matveychuk ну начнём с того, мадель, которую было бы правильнее называть activerecord которая не особо строго говоря и матчится с ооп, и очень сильно шлёт в задницу принцип единой ответсвенности и другие лучшие принципы ооп и хорошей архитектуры. И что делать в таком случае(фет модел) , если нужно обработать 5 моделей за один запрос? Устраивать ад зависимостей?) Или что произойдёт с приложением, если добавится 6 модель в запросе? Ну батенька, с такими моделями только про хорошую архитектуру и мечтать)
P.S. Как вообще можно приводить в пример архитектуры с yii?)))
@@sivr5vs38 Ну модель - это не обязательно ActiveRecord. Модель это Model, а активрекорд - это её наследник, ещё и не прямой, кажется, а через несколько уровней :) Но если мы будем говорить даже про актив-рекорд, то я не вижу там особого нарушения принципа единой ответственности. Сначала надо понять, что активрекорд - это запись в хранилище данных, а точнее её объектный аналог, потому разные методы link, unlink, save и прочее, тут находятся вполне к месту. Не к месту тут только метод find вероятно, так как сильно выбивается из абстракции самого объекта. Я, разумеется, могу быть в чём-то неправ, ну тогда лучше рассмотреть конкретный случай нарушения принципа единой ответственности в активрекордах.
Аргумент насчёт сложных связей тоже не понял. Если я за один запрос принимаю форму для 5-ти моделей, то, по идее эта форма может и реализовать методы работы с "подчинёнными" ей моделями в условиях этого запроса. Если же я принимаю форму для одной модели, но при её создании должны создаться ещё 4 с какими-то служебными данными, то этим как-раз должна заниматься основная модель, потому что без этих данных она не имеет смысла. Ну как я говорил, если мы видим, что работая с моделями мы постоянно вынуждены копаться в ненужных деталях реализации, то вполне можно вместо моделей создавать сервисы и модели скрывать за ними, только в этом случае следует соблюдать важное правило - контроллеры и представления должны полностью забыть о том, что в системе есть модели, и работать исключительно с сервисами, которыми эти модели обслуживаются (иначе получится абстракция с большой дырой, что неизбежно приведёт к проблемам и запутанному коду).
Nikolay Matveychuk в конце своего поста ты таки неявно продублировал автора видео. Но подожди, как работа с базой данных или файлом на диске может быть в зоне одной ответсвенности с расчетом скидки пользователя в зависимости от его дня рождения, к примеру? И кто говорил, что есть форма для реквеста? Это может быть хелзчек, который собирает данные по железу, агрегирует/мутирует/разукрашивает и записывает их в локальную базу или в стдаут в зависимости от времени суток и четности последней цифры в айпишнике хоста. Ну и этот хелзчек ещё дергается каким-нибудь кроном
@@sivr5vs38 в смысле неявно продублировал? я в комменте к видео явно указал, что продублировал, и даже пояснил почему (потому что писал коммент во время просмотра ставя на паузу, и предложил это решение не зная, что оно идёт далее в этом видео). "Это может быть хелзчек, который собирает данные по железу, агрегирует/мутирует/разукрашивает" - значит нужна форма (модель внешнего по отношению к системе источника данных), которая может собрать данные из этого источника. Значит она соберёт данные, провалидирует их и при запросе выдаст в удобоваримом системе формате (функции получения, валидации и передачи данных вызовет контроллер, саму логику этих функций реализует уже форма). При этом работать мы будем не с activerecord, а с чистыми моделями, потому что в данном случае получается, что данные системы находятся не в базе, а над уровнем базы, следовательно нам придётся винтить ещё и прослойку репозиториев (в которых теперь будут инкапулированы активрекорды и модели/формы для работы с другими каналами).
@@nikolaymatveychuk6145 модель для работы с моделями? Хм, а не сервис ли это получается?
Если загуглить "Django API Domains", то можно найти трактат, где ребята пошли ещё дальше, чем просто services.
Я до сих пор жалею, что слишком поздно о нем узнал. Есть у меня несколько проектов, где такой подход избавил бы от множества костылей.
Но переходить от ForeignKey к UUID - это очень трудоемкая задача для уже готового проекта.
а перевод на русский язык есть трактата? или это считается нонсенс
Просто шикарно.
Спасибо!
Задача контроллера - превратить request в response. Все просто и понятно.
Спасибо за видео, ты молодец!
Спасибо!
Відео годнота!
Спасибо
Можете снять ролик где более подробно расскажите о создание правильной архитектуры с джанго на каких то близких к реалиям примерах?
Спасибо! Такое видео будет
блин. Ну про Джангу прям молодец! Но есть вопрос. У Вас слой сервисов работает по принципу паттерна репозиторий? (для того, чтобы достать все заказы к примеру вы используете методы модели или так же делаете прослойку этих методов в сервисном слое?)
выяснение/согласование тех задания - это один из пунктов архитектуры, в любой книге по архитектуре программирования это есть, последующие пункты так же важны как и этот, нет смысла не изучить всю архитектуру, если занимаешься программированием...
Джавашные либы это Spring. Он из коробки даёт DI и некурильщик создает контроллер, ставит над ним аннотацию (в питоне это вроде декоратор) @Controller, создаёт интерфейс сервиса (без реализации), создаёт класс имплементирующий интерфейс сервиса и ставит над ним @Serivce. В классе контроллера создает поле типа интерфейса сервиса и ставит над ним аннотацию @Inject. Ну всё, дальше спринг делает магию DI при запуске.
Спасибо
Здравствуйте!
Пишу свой первый проект и есть немного каши в голове. Если я создаю контроллер, который возвращает конкретную страницу участника блога с деталями, и в шаблоне во время использования template engine и обхода authors в цикле, использую {{ author.article_set.count }} то получается, что я делаю запрос в бд из шаблона, и это нарушение mvc(mtv) паттерна?
Доступным языком, не плохо)
Спасибо
Когда проект небольшой, сложно читать бизнес в одном месте, а визуализацию в другом.
Мне нравиться когда все в одном месте, но проектировка так, что это все кратко.
Например:
- Читаю базу корзины, и вывожу ее в нужную переменную которая потом отобразтся.
- Удалить из корзины, удаляю и сразу отображаю..
file #1: db.insert(...); logicKorzina; viewBar += ''
file #2: db.del(...); logicKorzina; viewBar += ''
По поводу джанговых моделей и сервисов, я бы предложил другой подход, который выглядит логичнее.
А именно - модели это не только отображение БД, это объекты реального мира.
Например модель User если мы получим один объект, то это явно какой-то конкретный пользователь. Если нам нужно что-то с этим пользователем сделать - то эту логику логично будет писать в моделе User, т.к. вот прям тут с ним и происходит какое-то действие и из этой точки очень простой доступ к БД и аттрибутам пользователя.
Мы определили куда складывать логику для взаимодействия с одним объектом реального мира. А если мы взаимодействуем между объектами или логика подразумевает поэтапное использование других объектов? Тогда как-раз подойдет подход с сервисами - туда мы как раз можем положить логику взаимодействия с несколькими моделями.
А по поводу логики во вью - тут тоже может быть некая бизнес логика, а именно - принять данные, отправить их в форму, проверить что форма валидна, вызвать определенную бизнес логику из сервисов (модели), вернуть ответ.
За такой видос, ссылку в ВК опубликовал. Спасибо
Спасибо!
Недавно начал смотреть Django просто для расширения кругозора.
Было странно видеть разделение models, view, templates, кроме
того, почему в каждом из файлов содержится сразу несколько классов, это ведь неудобно?
Далее меня удивило то, что в моделях должна содержатся вся бизнес логика + логика работы с БД.
По крайней мере такое впечатление складывается когда смотришь
документацию и некоторые проекты на github.
Со слов автора видео понял что так делают не все, что радует.
По поводу бизнес логики, я бы вынес ее в отдельное место и назвал бы это Domain, Services как по мне это больше служебные классы.
Для запросов в БД есть паттерн Repository, для более сложных случаев можно использовать Specification.
Модели в данном случае оставить просто как маппинг на таблицы БД.
К слову, например в том же Symfony PHP фреймворке все организовано куда интересней.
Есть ли ссылка на более подробное описание в примерах реализации services в django?
Ссылки нет. Думаю, разберём на живом примере как-нибудь
ua-cam.com/video/yG3ZdxBb1oo/v-deo.html
спасибо
Я так и не научился по человечески писать код на PHP,, но мой велосипед потихоньку приходит к модели MVC :)
Вы на верном пути и это главное!
Классное видео, а где можно увидеть пример реализации слоя "services" в Django ? Или может будет такое видео?
В этом докладе вроде были примеры. Собственно, весь доклад про это
ua-cam.com/video/yG3ZdxBb1oo/v-deo.html
@@nkhitrov спасибо большое)
Спасибо за видео, пишу не на Питоне, но проблемы ровно те же в коде встречаю)
Часто попадается код в CRUDах, где из контроллера вызывается Repository. По факту та же история что и с Model из View, правильно?
По поводу отсутствия в Django возможности обратиться к БД из шаблона: разве код {{ foo.bar_set.all }} в шаблоне не приведет к запросу?
Случайно набрёл на Ваш канал. Понравились видео по Vim, так как сам являюсь его горячим поклонником после Emacs, и по tmux. Особенно как их объединить для разработки. По MVC тоже понравилось, хоть с этой темой был знаком и ранее. Про Rust ваша фраза повеселила. Сам являюсь поклонником Rust и Golang. В них как раз нет классов и классам объявлен бой. Хотелось бы послушать рассуждения на эту тему или что нибудь по языку Rust. Python недолюбливаю. Относительно минимализма и vim с Вами полностью согласен. Стараюсь IDE не использовать совсем и работать в консоли. Спасибо и удачи каналу.
Спасибо! Думаю, по Golang будут материалы на канале:) по Rust в ближайшее время, наверное, нет
Да, интересно посмотреть по Golang. К тому же в Vim есть плагины для работы с этим языком.
Впечатляет как вы управляетесь с Python. Не совсем понятно как вы его используете в проектах. Это или скрипты, которые обрабатывают данные, или WEB приложения на Python?
Пишем и скрипты любые на питоне, в тч по обработке данных, и веб приложения
Golang как раз рассматриваю как замену узких мест питона
Golang для сетевых приложений очень хорош. В Python мне не нравится, что невозможно защитить код программы при передаче заказчику, что не всегда удобно или приходится шаманить с обёртками. Golang язык компилируемый. Также в Python табы управляют логикой программы. Да, код без скобок и точек с запятыми выглядит чище, но ошибки в отступе строк приводят к ошибкам в исполнении интерпретатором. С другой стороны конечно в Python очень много библиотек.
Огромное спасибо. Я уже успел задуматься, почему view, когда там обрабатываются запросы. Твоё решение кажется супер крутым, спасибо. Конкретно в моем случае, очень поможет. Не мог бы ты или другие люди в коментах ответить на мои вопросы?
Я реализую приложение для документооборота.
1) Имеется несколько должностей работников, для каждой описал отдельный модуль.
Поскольку у работника может быть несколько ставок, сделал такую связь: User -> Worker -> WorkerPosition
Не смог понять структуру классов/таблиц и что за данные в них по описанию - надо вникать более глубоко, чтобы ответить на вопросы
В очередной раз убеждаюсь, что все эти подходы типа mvc не имеют смысла в качестве инструкций. Да, есть models.py, где лежит список сущностей и порядок работы с ними. Никто не мешает, если файл раздулся или требуется переиспользование, вынести функцию наверх файла или в отдельный файл. Точно также никто не мешает, если views.py стал нечитабельно-огромным или нужно переиспользование, вынести именно эту логику в отдельный файл и импортировать его куда надо, когда это понадобилось. Но также нет ничего плохого в том, чтобы написать логику внутри views.py. Просто естественно всегда надо думать немного наперед, разделять и переиспользовать. А когда вы по инструкции придерживаетесь всяких стандартов, то лезть за двумя строками в какие-то сервисы - ну зачем? Код - это творчество. Хорошим кодом ценители восторгаются также, как и картиной, например. В живописи тоже куча техник и подходов, весьма четко описанных, творчества там ноль. А хорошие картины ведь часто получаются на стыках этих технологий, когда худохник не тупо их использует, а знает, когда лучше так, а когда - иначе, вот и тут также.
Приветствую!
1. Огромное спасибо за контент! Всегда приятно смотреть и слушать!
2. Можно ли получить пример по данному видео?! Хотелось бы наглядно посмотреть на организацию и логику распределения функций/классов/etc...
Это код одного из наших проектов, не могу его показать. Но сделаем какой-то живой пример может быть на стриме, на нем все будет понятно
Диджитализируй! АйТи студия я понял сразу какой это проект :) Поэтому и попросил что-то на коленке - петпроджект какой-то изобрести с той структурой, которую описываете.
Собственно говоря меня именно этот момент все время тормозит в Джанго 😩
@@jtprogru_channel да, сделаем!
Очень правильное видео, побольше бы таких.
Стараюсь выносить логику в utils, не расширяя модели и контроллеры, но есть один очень непонятный момент в этом. 1) Джанга, как и DRF, содержит в контроллерах методы в стиле get_queryset и т.д., которые обращаются к модели и БД. Разве это ок? Конечно, можно заставить эти методы работать через сервисы, но насколько это практично, переопределять метод получения кверисета через сервис, дополнительно писать этот сервис? (Вариант с товарами надуман, т.к. там явно будет много логики, но, думаю, посыл понятен). 2) Пагинация - тоже вроде как бизнес логика, но в контроллере смотрится весьма гармонично. Что с ней? 3) Сериалайзеры - что делать с ними? Они неплохо смотрятся как "входной шлюз" для данных, которые мы получили в реквесте. Тоже их в сервис? 4) И сколько потом будет таких сервисов? Не получится ли какая-то каша, если для каждого чиха будет сервис? 5) Менеджеры - стоит ли вообще писать кастомы? Иногда удобно, но для себя пока не решил.
В последнее время очень много задумываюсь над архитектурой и пробую выносить логику в сервисы, но озвученные выше вопросы не дают покоя.
3:20 Сортировку массива перед показом можно в отображение запихнуть? (при условии что в бизнес модели этот массив отсортированный не используется)
Я думаю, что да, это может быть логикой отображения. Не все шаблонизаторы это поддерживают, поэтому можно перенести это в контроллер. Частые задачи контроллера это форматирование, сортировка данных, пришедших от модели, и затем уже передача их в отображение
@@t0digital Спасибо!
8:00 жиза.. всё круто
Не раз возвращаюсь к этому ролику) у тебя очень позитивные и полезные видео, так держать! :)
Может подскажешь, что лучше использовать для вида приложения в веб: чистый css (scss) или bootstrap?)
P.S. Сейчас перехожу с flask на django
Если по-быстрому и особо не вникать, то фреймворки, а так лучше css изучить чистый, он сейчас модный и достаточно простой в использовании
Здравствуйте, я тоже пришел к такому выводу и всю бизнес логику выносил в файл (пакет если он разрастается) под названием utils. Потому что в представлениях совсем не то место, а модели сильно распухают и плохо тестируются потом. Это надо пройти на своем опыте(!). Интересно было бы взглянуть на структуру этого пакета у Вас
Название services мне нравится гораздо больше. Погуглил - это действительно очень распространенный подход а я дошел до него только после года фриланса и работы работы над приложениями за зарплалу. Как же многого мы (я) еще не знаем...
Спасибо за видео. Хотелось бы узнать, планируется ли раскрытие таких тем как Domain Driven Design, Test-Driven Development и т.п. ? Заранее спасибо за ответ.)
Да, обязательно будет
@@t0digital Отлично)
Во многих фреймворках новички пишут бизнес-логику в моделях, т. к. им кажется, что больше негде. Опытные люди обычно выносят бизнес-логику в сервисы, а в моделях остаётся только структура данных.
Это вы про микросервисную архитектуру ?!
@@bobobo500 Нет. Под сервисами я подразумеваю вспомогательные классы.
Расскажите про контроль версий для проектов (для файллв и для бд)?
про Git будет материал. Версионность БД в минимальном виде это механизм миграций в Django, аналогичный есть в других фреймворках
Очень крутое видео! Объяснил много моментов, на которые негде было найти ответы. Но один вопрос ещё остался: Model.objects.all() и подобные вызовы тоже выносить в сервисы? Если да, то как это делать правильно? Было бы очень круто, если бы ты сделал видео с наглядным примером как именно что либо выносится в отдельный слой!
Я вообще все во вьюхах делал🤦🏻♂️ а оказывается, что это говнокод😁
@@maksimangerman6238 жиза)
Вот есть вопрос. Про модели в Джанго согласен полностью, как и вообще со всем видео, но... В одной книге, проверка пароля, определяется в классе модели, а вызов этого метода происходит в views.py, т.е. в модели. Выглядит вроде прилично. По опыту, можно так отступать, или лучше вывести это в отдельный класс? И про миксины хотелось бы узнать мнение. Если к примеру вывести часть бизнес-логики в миксин, не нарушит ли это MVC?
с миксинами надо быть аккуратненько, это множественное наследование, можно выстрелить себе в ногу случайно. Миксины должны быть очень маленькими и минималистичными, а бизнес-логика такой бывает редко
А пример джанго проекта с правильной бизнес-логикой можешь показать, а то в итоге какая-то дыра... там писать нельзя, тут тоже нельзя, зато можно вон там в уголочке, но вот как это делать не совсем понятно(совсем непонятно)
Так он же показал. Делаешь отдельный пакет и там строчишь бизнес-логику. Потом подтягиваешь её во views.
@@caesarfatalhammer я не говорил про бизнес. Я попросил показать практически правильное решение того, о чем он говорит. Потому что, как сказал автор, большинство пишет бизнес-логику в моделях или во вьюхах.
Подхода, о котором он говорит, я не встречал ни в одном уроке, поэтому соответствующая просьба.
Так что твой ядовитый высер здесь ни о чем...
@@WorldCount Ну он показал как это выглядит(как папочки лежать должны), а я прошу о тупом примере работы этих сервисов. Потому что мне непонятно зачем выводить в отдельный сервис, например, добавление товара в корзину, или оформление заказа, если мы говорим об интернет-магазине. Таким образом получится, что во вьюхе останется 2 строчки кода (вызов сервиса и return какие-то данные). Вот в этом вопрос. Зачем такое сильное дробление?
Предполагаю, что в больших проектах оно необходимо. Я в таких не участвовал. Поэтому хочу услышать ответ от опытного человека, который занимается тем, что делится знаниями посредством своего ютуб канала. Зачем отдельный пакет с сервисами и почему это эффективнее, чем писать методы к моделям и писать БЛ во вьюхах.
@@MrBytmin Спасибо за развернутый комментарий. Действительно в видео об этом говорилось, но почему-то не уложилось по полочкам. После вашего ответа стало немного понятнее.
Но все же посмотрев на код, было бы еще понятнее))
"правильной бизнес-логикой"
Для меня например загадка зачем тащить MVC в Джангу. Правильным скорее будет то, что по дефолту. А по дефолту в Джанге - MVT.
То есть в services пилить логику, а во views оставить только return render?
Неплохо, но упущено много важных моментов. Не всегда и не везде есть принципиальная возможность выносить всю логику за пределы view-метода. Как быть если нам нужно проверить атрибуты объекта ещё до момента инициализации сериализатора? Что если у нас имеется over-100500 полей и параметров, с которыми работает сервис? А если мы в одном запросе работаем с объектами разных типов, получится ли это сделать без затрагивания слоя представлений?
Алексей, а можете подробно рассказать как устроен Django изнутри? Как там с роутингом работать, как модели создавать, либо импортировать из готовых баз, как правильно писать шаблоны и вьюшки, как и где правильно писать бизнес-логику. Советы для начинающих, чтоб обойти подводные камни на этапе изучения фреймворка и представление о том что к чему уже складывалось в голове.
А то вот сейчас столкнулся с кучей вопросов и проблем на этапе изучения (даже с роутингом не могу толком разобраться и логику всю во вьюшках пишу), сижу курю документацию днями и ночами, пытаясь понять что к чему)))
Согласен.Помню писал сайт обьявлений - тупо делил на апсы без использования бизнес логики(Использовал только отдельные тулы).Недавно договорился заказчиком на саппорт сайта.Ну вот - поплыл в своем коде
однозначный лайк! Извините, Автор, забыл Ваше имя. Анонс круса будет?
классная кружка в японском стиле =)
Спасибо:) нравится тоже:)
Всегда нравились аргументы типа - "Это бред, это бред"
Очевидно мне тоже
Здравствуйте. Вопрос мучает меня. Пишу MVC приложение на C#. Нужно получать записи с учётом пагинации, фильтров, сортировки и всё это в разных комбинациях. Не хочется плодить кучу методов для разных вариантов выборки данных в сервисе, да и выглядит это, как задачи контроллера.
Как правильно решать такие ситуации? Давать доступ контроллеру к орм для выборки, или добавлять методы в сервис?
Привет! Не надо ходить в ORM из контроллера, эту логику надо выносить в отдельный слой 100%. Как именно на уровне бизнес логики её лучше сделать вопрос второй, но все фильтрации и подобное должны быть там. Сортировка данных на мой взгляд допустима в контроллере, но фильтры в отдельном слое.
@@t0digital Спасибо. Было устойчивое желание опустить слой бизнес логики, а тут ваше видео.
Лайк, если "Здаров, котаны" было лучше
Я правильно понял. Что добавление товара в корзину лучше не делать во View приложения. А поручить это например api rest?
API REST не имеет никакого отношения к теме вопроса. Во View добавления товара в корзину быть не должно, View должен вызывать функции добавления в корзину, определенные не во View.
она встречается на каждом первом проекте :)))))))))))))