Какой же душевный у тебя контент. Как будто с корешем на кухне болтаю. Мне лично очень заходит такой подход, удачи в развитии канала!

@t0digital

4 жыл бұрын

Спасибо, очень приятно!

@xm4dn355x

4 жыл бұрын

Тут сложно не согласиться)

@Nastya99_99

4 жыл бұрын

Тема супер. После первого знакомства с джангой я как то неделю пытался найти в интернете куда же нужно пихать бизнес логику. Так и не нашёл кстати) Но пришёл к тому же способу как в видео

@t0digital

4 жыл бұрын

@@Nastya99_99 отлично! Странно, что Django не даёт нормальных рекомендаций в своей же доке

@user-xv1iq3km2w

3 жыл бұрын

@@t0digital Да, отдельный респект за это, никогда так не было приятно слушать материал

Уже 4 раз пересматриваю и возвращаюсь к этому видео, 20 минут концентрированной, крутой информации! Спасибо!

Спасибо за подробное объяснение! Все объяснения, которые я встречал до этого, были настолько абстрактными, что больше путался чем понимал

Такого понятного объяснения MVC я ещё нигде не встречал

Очень полезно! Был бы тех диром, заставил бы всех джанговодов посмотреть этот ролик. Спасибо

Здравствуйте. Отличное видео. Слушать вас можно часами. Сам я работаю с Ruby и RoR. Недавно заинтересовался в джанге и сейчас уже делаю проекты и на RoR и на Джанге. Я был удивлен когда узнал, что в Джанге MVT архитектура. Действительно из-за этого код пишется то в view, то в моделях. Возможно изначально Джанга задумывалась не только как веб фреймворк. Поэтому здесь нет такого жёсткого разделения. В каждом проекте ты можешь тонко настроить всё под свои нужды. В рельсах хоть и MVC, но бизнес логику ты тоже пишешь в сервисах. Хотелось бы увидеть с вашей точки зрения топ проектов на Джанге на гитхабе с хорошим кодом. Спасибо.

Спасибо, лайк. Жду новых видео про архитектуру и паттерны

Отличное видео! Очень полезно и информативно. Теория ясна, теперь ждём видео с практикой модель-вью-контроллер. Не хватает таких видео, где всё архитектурно грамотно и красиво, чтобы понимать как оно происходит.

@t0digital

4 жыл бұрын

Обязательно будет живой пример. Спасибо!

@canada946

4 жыл бұрын

Диджитализируй! АйТи студия а ещё если можно, расскажите как можно использовать одно приложение Джанго (не проект) в нескольких проектах, если такое вообще возможно. Как наоборот сделать (один проект, много приложений) понятно :)

Давно сам задумывался о данном вопросе в Django. Сколько раз этот момент обсуждали с коллегами. Мы всю бизнес-логику выносим в фасады.

Лайк, на 1000% согласен! И про нейминг и про вопрос - где писать бизнес логику в Django

Отличная информация и ее подача, все доступно и наглядно. Большое спасибо!

@t0digital

3 жыл бұрын

Спасибо, рад, что полезно!

Спасибо, очень доступно объясняешь, кажется я начал кое что понимать)

@t0digital

4 жыл бұрын

Отлично, рад, что полезно!

БлагоДарю за такую замечательную подачу материала. Хотелось бы в роликах увидеть подробности, как правильно организовывать архитектуру кода при написании простого приложения (или отдельной функции бизнес-логики) соблюдая принципы DRY.

@t0digital

4 жыл бұрын

покажу как-нибудь в живом примере, да!

Как раз вовремя. Начал проект на джанго и мучался вопросом куда бизнес логику писать. Как раз начитался противоречивых советов, что во вьюху/модель писать. Потом посоветовали вообще рест фреймворк. Взрыв мозга. А тут всё по делу и понятно, спасибо.

@t0digital

4 жыл бұрын

Отлично!

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер - таким образом, что модификация каждого компонента может осуществляться независимо

Так бы и сидел все время и слушал ваше объяснение. Очень интересно объясняете. Спасибо!

@t0digital

Жыл бұрын

Спасибооо!

На самом деле стало понятно, как MVC укладывается в django ) а то поназывали там views это контроллер... бр, спасибо, что разъяснили!

Спасибо, хорошо, что у тебя посмотрел, чтобы как говорится, сразу правильно делать, а не переучиваться потом )

Большое спасибо за видео. Было очень интересно и с именованием и хранением в services было ново и полезно.

@t0digital

4 жыл бұрын

Отлично! Рад, что полезно

Кстати, давно уже задавался вопросом, где же в джанге бизнес прикручивать. Теперь знаю. Как раз вовремя видео подошло! Спасибо!

@t0digital

4 жыл бұрын

Отлично!

На восьмой минуте понял, что ничего не понятно, но, очень интересно. В любом случае, спасибо, Котан!

Спасибо, отличная тема!!!) Если подытожить, в джанго советуешь делать: 1.модуль service - файлы (скрипты) с бизнес логикой (запросы к бд и другие работы с данными) 2. views.py - контроллер 3. Ну и шаблоны это понятно отображение (views из mvc) Так?)

@t0digital

4 жыл бұрын

Да, и models.py это ORM классы и возможно совсем чуть-чуть бизнес логики

Единственный канал, где меня с экрана называли "Котаном". раньше......

@TheTruepikvic

4 жыл бұрын

Да, хороший был канал 😊

@kosatchev

4 жыл бұрын

Да, что с котанами?

Хоспади, как же круто вы рассказываете!!! Спасибо!!

@t0digital

3 жыл бұрын

Спасибо!

Спасибо за актуальное видео!)) Как раз делаю проект на джанге.

@t0digital

4 жыл бұрын

models.py - это модели Django, отображающие структуру БД

@user-rs5zq9hy4m

4 жыл бұрын

@@t0digital еще несколько раз пересмотрел, чтоб понять mvc что такое и как в джанго это реализовано))

Отличный канал! Суперская подача материала! Высокий уровень! Автору -- респект, котанам -- привет!

@t0digital

4 жыл бұрын

Спасибооо💪!

Спасибо за четкое, понятное объяснение. Молодца

Класс! Наконец-то это ктото объяснил. Вы - спасение

Как же вовремя это видео, когда пошел на курс по джанго... Очень хочется делать красиво. Хотелось бы подробнее с технической части, взглянуть на структуру проекта. Плохо понятно со скриншота, ну папочки там какие-то, и что? django-service-objects юзать стоит? В дзене питона вон говорят, что проще - лучше и вообще главное, чтоб работало. Не все наслышаны о MVC (тем более очевидно, раз в каждом 1ом проекте такие косяки), стоит развить эту тему! Помог начать задавать правильные вопросы, спасибо!=)

@senatortre7326

4 жыл бұрын

kzread.info/dash/bejne/q3tnvMaxcsWXn9I.html многое поясняет данная лекция.

Спасибо! Настолько все очевидно и логично, что даже странно, что кто то делает иначе!!!

@t0digital

4 жыл бұрын

странно, но факт:)

Спасибо за видео! Очень доходчиво.

Спасибо! Очень круто

Спасибо! Ещё раз упорядоченно об этом услышал

ОЧЕ круто, ну вот теперь то наконец-то дошло (надеюсь)).

@t0digital

4 жыл бұрын

Отлично

Вообще сами разработчики Джанго говорят что контроллеры в Джанго это скорей urls.py а бизнес логику рекомендуют писать в models.py. В компании которой я работаю сейчас, мы тоже используем подход с services & selectors(места для агрегации данных) и мы это унаследовали от Болгарский компании hacksoftware которая одна из первых описала стайлгайд для такого стиля архитектуры для Джанго;) и это подход достаточно удобен на практике)

Расскажи, пожалуйста, в отдельном видосе как ты проектируешь структуру классов, как описываешь интерфейсы и т.д.

Респектую ребята!!! Отличное объяснение!

@t0digital

4 жыл бұрын

Спасибо!

Как раз в универе недавно проходили MVC, суть та же. Спасибо, что разобрали, так понятней стало

@t0digital

4 жыл бұрын

Отлично!

@notrlt

Жыл бұрын

У вас в универе проходят мвс? А это где?

Спасибо за видео! Хотелось бы увидеть пример, где "плохо", а где "хорошо"

@t0digital

3 жыл бұрын

Посмотрите код ревью, несколько видео есть на канале

Спасибо, только учусь, инфа важная)

Январь 2023 года. И Вы открыли мне глаза) спасибо Вам!)

@maksimangerman6238

Жыл бұрын

upd: И действительно очень ламповые и приятные выпуски.

Сделай пожалуйста видос про выбор лицензии проекта при создании репозитори на гитхабе. в чём между ними различия и какую для какого проекта лучше выбрать.

И тут все круто! Спасибо, кодер, от Котана ))))

@t0digital

4 жыл бұрын

Спасибо 🙏

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, скорее всего нет.

Более того, должен быть слой контроллера, слой сервиса, слой репозитория, слой респонс-сервиса, и каждый друг для друга есть «чёрный ящик». Работаю по такой архитектуре со Spring и JavaEE (Jakarta EE), и все великолепно поддерживается. Однако, наговнокодить можно умудриться везде, если к тому душа лежит )

Здравствуйте спасибо за разъяснение!Подскажите пожалуйста есть пример кода на джанго которое можно посмотреть )

Привет! Спасибо за ролик! Можешь выкинуть пример кода который "плох" и который "хорош"? Я думаю есть примеры на гитхабе. Потому что не совсем понятно данное разделение. Во всяком случае для меня.

@t0digital

4 жыл бұрын

посмотрю что-нибудь, может на живом примере разберем

@namalnikmisartenko8785

4 жыл бұрын

@@t0digital Отлично.

@user-gw6js5ph6g

4 жыл бұрын

@@t0digital Да, было супер!

@dvornikxilosof799

4 жыл бұрын

@@t0digital Спасибо огромное за видео, реально топчик. Если есть пример правильной архитектуры на Django(имеется в виду на гите мб видел) кинь пж. Сейчас работаю над проектом где django, много apps, и все сделанно во views,еще и celery, который делает одно и то же. Хотелось бы узнать как правильно делать и как исправлять это. Потому что дебажить это ад. Еще раз спасибо за видео. Если проигноришь - НЕ обижусь: все мы люди и времени на каждого у тебя нет)))

@t0digital

4 жыл бұрын

@@dvornikxilosof799 думаю, сделаем приложеньку на джанге и там все покажу

Отличная лекция получилась, спасибо.

@t0digital

5 ай бұрын

Спасибо!

Спасибо, очень полезно!

Відео годнота! Спасибо Можете снять ролик где более подробно расскажите о создание правильной архитектуры с джанго на каких то близких к реалиям примерах?

@t0digital

4 жыл бұрын

Спасибо! Такое видео будет

Мне понравилось решение в фреймворке fastAPI, там например вынесли бизнес-логику в отдельный модуль, в доке у них CRUD так выделили. Конечно добавляется ещё один слой, но выглядит масштабируемо и упорядоченно. В джанге, почему-то, в доке такого не показывают.

В отображении не должно быть логики - да, обычно когда такое говорят, имеют ввиду именно бизнес логику :) Это такое сокращение, которое обычно воспринимается как очевидное. Контроллер плохо называть клеем между (моделями) бизнес логикой и представлениями (отображением). У контроллера есть одна основная задача - обработать запрос. То есть ему надо принять решение о том, что хочет пользователь, выполнить нужные действия, и показать пользователю ответ. Иначе, если бы контроллер был клеем между моделями и представлениями, то по данному шаблону было бы запрещено отправлять модели с данными в представления, а нужно было бы их разбирать на массивы и отправлять только массивы. В контроллере запрещена работа с БД через ORM? :) То есть если пользователь запросил у сайта данные о своих покупках за последний месяц, то я не могу выполнить Order::find()->andWhere(список_условий)->all(), и мне надо это куда-то в статический метод моделей совать? Это неверное утверждение, я считаю... нет ничего плохого в том, чтобы контроллер запросил данные откуда ему угодно, главное, чтобы он эти данные сам не генерировал (не считал). Как я говорил, его задача в том, чтобы понять запрос, выполнить его, и отобразить необходимые данные (а идея о том, что там не должно быть запросов в БД скорее всего родилась из утверждения, что контроллер - это всего лишь клей без какой либо собственной функции). Насчёт записи данных - ну контроллер вполне может принять формы с данными, запустить в них процесс валидации, если он прошёл успешно, то рассовать данные по моделям и вызвать метод сохранения моделей. Под сохранением айфонов в БД это имелось ввиду? :) Если да, то в этом нет ничего преступного, потому что это всё ещё исключительно обработка запроса, и если тело запроса вдруг надо будет изменить для другого приложения, то и обработка этого запроса будет другой, а значит нам в любом случае именно эта логика будет мало полезна :) "не предлагает места, где писать бизнес логику" - эм :)) бизнес логику надо писать в моделях (yii, yii2 тоже не предлагают никаких других мест для неё), потому что именно там ей и место. Предполагается, что модель - это самый типичный объект парадигмы ООП, то есть сущность, которая соответствует объекту реального мира и имеет свои свойства и методы для работы с ним. Потому да, логику пишем исключительно на уровне моделей и именно в них самих. Если же нам нужна абстракция не настолько большая, как "модуль", но и не настолько детальная, как "модель", то для этого паттерн MVC можно расширить такой штукой как "Service layer" (паттерн такой), когда контроллер, обрабатывая запросы, дёргает не методы моделей, а вызывает функции сервисов, которые в свою очередь уже дёргают методы моделей. (АХАХА.... пишу сообщение во время просмотра видео, снимаю с паузы, а тут "для этого создаём свой слой Бизнес логики, называем его services"... ну вот тут согласен полностью xD только это не джавовая фишка такая, а полноценный паттерн) P.S. Судя по тому, что говорится в видео, у автора не совсем верное представление о том, что такое бизнес логика. :) Бизнес логика - это то, что с точки зрения пользователя происходит за кулисами (то, о чём он не просил, но что произошло в силу необходимости для бизнеса), при этом так, как контроллер лишь обрабатывает запрос, мы можем себе представить, что вместо него мы и посадили очень умного пользователя. Вот он решил купить телефон, что он сделает, если он умный? - Попросит "покажи мне список всех телефонов с ценой от 10к до 20к рублей" - Сохрани пожалуйста мой заказ и покажи что мне надо сделать, чтобы его получить (например оплатить, выбрать дату доставки и т.д.) - Сохрани [вот эти] дополнительные данные по заказу и отправь меня оплачивать заказ - Скажи всё ли ты правильно принял, когда и на каких условиях ждать мой заказ Вот всё это - это то, с чем контроллер обращается к уровню моделей :) И это не является бизнес логикой, а вот всё остальное, что делает система (например расчёт скидок, отправка писем, передача заявок в разные CRM системы и т.д.) - это уже бизнес логика.

@sivr5vs38

4 жыл бұрын

Nikolay Matveychuk ну начнём с того, мадель, которую было бы правильнее называть activerecord которая не особо строго говоря и матчится с ооп, и очень сильно шлёт в задницу принцип единой ответсвенности и другие лучшие принципы ооп и хорошей архитектуры. И что делать в таком случае(фет модел) , если нужно обработать 5 моделей за один запрос? Устраивать ад зависимостей?) Или что произойдёт с приложением, если добавится 6 модель в запросе? Ну батенька, с такими моделями только про хорошую архитектуру и мечтать) P.S. Как вообще можно приводить в пример архитектуры с yii?)))

@nikolaymatveychuk6145

4 жыл бұрын

@@sivr5vs38 Ну модель - это не обязательно ActiveRecord. Модель это Model, а активрекорд - это её наследник, ещё и не прямой, кажется, а через несколько уровней :) Но если мы будем говорить даже про актив-рекорд, то я не вижу там особого нарушения принципа единой ответственности. Сначала надо понять, что активрекорд - это запись в хранилище данных, а точнее её объектный аналог, потому разные методы link, unlink, save и прочее, тут находятся вполне к месту. Не к месту тут только метод find вероятно, так как сильно выбивается из абстракции самого объекта. Я, разумеется, могу быть в чём-то неправ, ну тогда лучше рассмотреть конкретный случай нарушения принципа единой ответственности в активрекордах. Аргумент насчёт сложных связей тоже не понял. Если я за один запрос принимаю форму для 5-ти моделей, то, по идее эта форма может и реализовать методы работы с "подчинёнными" ей моделями в условиях этого запроса. Если же я принимаю форму для одной модели, но при её создании должны создаться ещё 4 с какими-то служебными данными, то этим как-раз должна заниматься основная модель, потому что без этих данных она не имеет смысла. Ну как я говорил, если мы видим, что работая с моделями мы постоянно вынуждены копаться в ненужных деталях реализации, то вполне можно вместо моделей создавать сервисы и модели скрывать за ними, только в этом случае следует соблюдать важное правило - контроллеры и представления должны полностью забыть о том, что в системе есть модели, и работать исключительно с сервисами, которыми эти модели обслуживаются (иначе получится абстракция с большой дырой, что неизбежно приведёт к проблемам и запутанному коду).

@sivr5vs38

4 жыл бұрын

Nikolay Matveychuk в конце своего поста ты таки неявно продублировал автора видео. Но подожди, как работа с базой данных или файлом на диске может быть в зоне одной ответсвенности с расчетом скидки пользователя в зависимости от его дня рождения, к примеру? И кто говорил, что есть форма для реквеста? Это может быть хелзчек, который собирает данные по железу, агрегирует/мутирует/разукрашивает и записывает их в локальную базу или в стдаут в зависимости от времени суток и четности последней цифры в айпишнике хоста. Ну и этот хелзчек ещё дергается каким-нибудь кроном

@nikolaymatveychuk6145

4 жыл бұрын

@@sivr5vs38 в смысле неявно продублировал? я в комменте к видео явно указал, что продублировал, и даже пояснил почему (потому что писал коммент во время просмотра ставя на паузу, и предложил это решение не зная, что оно идёт далее в этом видео). "Это может быть хелзчек, который собирает данные по железу, агрегирует/мутирует/разукрашивает" - значит нужна форма (модель внешнего по отношению к системе источника данных), которая может собрать данные из этого источника. Значит она соберёт данные, провалидирует их и при запросе выдаст в удобоваримом системе формате (функции получения, валидации и передачи данных вызовет контроллер, саму логику этих функций реализует уже форма). При этом работать мы будем не с activerecord, а с чистыми моделями, потому что в данном случае получается, что данные системы находятся не в базе, а над уровнем базы, следовательно нам придётся винтить ещё и прослойку репозиториев (в которых теперь будут инкапулированы активрекорды и модели/формы для работы с другими каналами).

@sivr5vs38

4 жыл бұрын

@@nikolaymatveychuk6145 модель для работы с моделями? Хм, а не сервис ли это получается?

выяснение/согласование тех задания - это один из пунктов архитектуры, в любой книге по архитектуре программирования это есть, последующие пункты так же важны как и этот, нет смысла не изучить всю архитектуру, если занимаешься программированием...

Джавашные либы это Spring. Он из коробки даёт DI и некурильщик создает контроллер, ставит над ним аннотацию (в питоне это вроде декоратор) @Controller, создаёт интерфейс сервиса (без реализации), создаёт класс имплементирующий интерфейс сервиса и ставит над ним @Serivce. В классе контроллера создает поле типа интерфейса сервиса и ставит над ним аннотацию @Inject. Ну всё, дальше спринг делает магию DI при запуске.

Если загуглить "Django API Domains", то можно найти трактат, где ребята пошли ещё дальше, чем просто services. Я до сих пор жалею, что слишком поздно о нем узнал. Есть у меня несколько проектов, где такой подход избавил бы от множества костылей. Но переходить от ForeignKey к UUID - это очень трудоемкая задача для уже готового проекта.

@zgrad2008

4 жыл бұрын

а перевод на русский язык есть трактата? или это считается нонсенс

Приветствую! 1. Огромное спасибо за контент! Всегда приятно смотреть и слушать! 2. Можно ли получить пример по данному видео?! Хотелось бы наглядно посмотреть на организацию и логику распределения функций/классов/etc...

@t0digital

4 жыл бұрын

Это код одного из наших проектов, не могу его показать. Но сделаем какой-то живой пример может быть на стриме, на нем все будет понятно

@jtprogru_channel

4 жыл бұрын

Диджитализируй! АйТи студия я понял сразу какой это проект :) Поэтому и попросил что-то на коленке - петпроджект какой-то изобрести с той структурой, которую описываете. Собственно говоря меня именно этот момент все время тормозит в Джанго 😩

@t0digital

4 жыл бұрын

@@jtprogru_channel да, сделаем!

Когда проект небольшой, сложно читать бизнес в одном месте, а визуализацию в другом. Мне нравиться когда все в одном месте, но проектировка так, что это все кратко. Например: - Читаю базу корзины, и вывожу ее в нужную переменную которая потом отобразтся. - Удалить из корзины, удаляю и сразу отображаю.. file #1: db.insert(...); logicKorzina; viewBar += '' file #2: db.del(...); logicKorzina; viewBar += ''

По поводу джанговых моделей и сервисов, я бы предложил другой подход, который выглядит логичнее. А именно - модели это не только отображение БД, это объекты реального мира. Например модель User если мы получим один объект, то это явно какой-то конкретный пользователь. Если нам нужно что-то с этим пользователем сделать - то эту логику логично будет писать в моделе User, т.к. вот прям тут с ним и происходит какое-то действие и из этой точки очень простой доступ к БД и аттрибутам пользователя. Мы определили куда складывать логику для взаимодействия с одним объектом реального мира. А если мы взаимодействуем между объектами или логика подразумевает поэтапное использование других объектов? Тогда как-раз подойдет подход с сервисами - туда мы как раз можем положить логику взаимодействия с несколькими моделями. А по поводу логики во вью - тут тоже может быть некая бизнес логика, а именно - принять данные, отправить их в форму, проверить что форма валидна, вызвать определенную бизнес логику из сервисов (модели), вернуть ответ.

Very Спасибо )) очень полезно

@t0digital

4 жыл бұрын

Рад, что полезно, спасибо!

блин. Ну про Джангу прям молодец! Но есть вопрос. У Вас слой сервисов работает по принципу паттерна репозиторий? (для того, чтобы достать все заказы к примеру вы используете методы модели или так же делаете прослойку этих методов в сервисном слое?)

Очень правильное видео, побольше бы таких. Стараюсь выносить логику в utils, не расширяя модели и контроллеры, но есть один очень непонятный момент в этом. 1) Джанга, как и DRF, содержит в контроллерах методы в стиле get_queryset и т.д., которые обращаются к модели и БД. Разве это ок? Конечно, можно заставить эти методы работать через сервисы, но насколько это практично, переопределять метод получения кверисета через сервис, дополнительно писать этот сервис? (Вариант с товарами надуман, т.к. там явно будет много логики, но, думаю, посыл понятен). 2) Пагинация - тоже вроде как бизнес логика, но в контроллере смотрится весьма гармонично. Что с ней? 3) Сериалайзеры - что делать с ними? Они неплохо смотрятся как "входной шлюз" для данных, которые мы получили в реквесте. Тоже их в сервис? 4) И сколько потом будет таких сервисов? Не получится ли какая-то каша, если для каждого чиха будет сервис? 5) Менеджеры - стоит ли вообще писать кастомы? Иногда удобно, но для себя пока не решил. В последнее время очень много задумываюсь над архитектурой и пробую выносить логику в сервисы, но озвученные выше вопросы не дают покоя.

Случайно набрёл на Ваш канал. Понравились видео по Vim, так как сам являюсь его горячим поклонником после Emacs, и по tmux. Особенно как их объединить для разработки. По MVC тоже понравилось, хоть с этой темой был знаком и ранее. Про Rust ваша фраза повеселила. Сам являюсь поклонником Rust и Golang. В них как раз нет классов и классам объявлен бой. Хотелось бы послушать рассуждения на эту тему или что нибудь по языку Rust. Python недолюбливаю. Относительно минимализма и vim с Вами полностью согласен. Стараюсь IDE не использовать совсем и работать в консоли. Спасибо и удачи каналу.

@t0digital

4 жыл бұрын

Спасибо! Думаю, по Golang будут материалы на канале:) по Rust в ближайшее время, наверное, нет

@DimiEG

4 жыл бұрын

Да, интересно посмотреть по Golang. К тому же в Vim есть плагины для работы с этим языком. Впечатляет как вы управляетесь с Python. Не совсем понятно как вы его используете в проектах. Это или скрипты, которые обрабатывают данные, или WEB приложения на Python?

@t0digital

4 жыл бұрын

Пишем и скрипты любые на питоне, в тч по обработке данных, и веб приложения

@t0digital

4 жыл бұрын

Golang как раз рассматриваю как замену узких мест питона

@DimiEG

4 жыл бұрын

Golang для сетевых приложений очень хорош. В Python мне не нравится, что невозможно защитить код программы при передаче заказчику, что не всегда удобно или приходится шаманить с обёртками. Golang язык компилируемый. Также в Python табы управляют логикой программы. Да, код без скобок и точек с запятыми выглядит чище, но ошибки в отступе строк приводят к ошибкам в исполнении интерпретатором. С другой стороны конечно в Python очень много библиотек.

Недавно начал смотреть Django просто для расширения кругозора. Было странно видеть разделение models, view, templates, кроме того, почему в каждом из файлов содержится сразу несколько классов, это ведь неудобно? Далее меня удивило то, что в моделях должна содержатся вся бизнес логика + логика работы с БД. По крайней мере такое впечатление складывается когда смотришь документацию и некоторые проекты на github. Со слов автора видео понял что так делают не все, что радует. По поводу бизнес логики, я бы вынес ее в отдельное место и назвал бы это Domain, Services как по мне это больше служебные классы. Для запросов в БД есть паттерн Repository, для более сложных случаев можно использовать Specification. Модели в данном случае оставить просто как маппинг на таблицы БД. К слову, например в том же Symfony PHP фреймворке все организовано куда интересней.

Классное видео, а где можно увидеть пример реализации слоя "services" в Django ? Или может будет такое видео?

@nkhitrov

4 жыл бұрын

В этом докладе вроде были примеры. Собственно, весь доклад про это kzread.info/dash/bejne/q3tnvMaxcsWXn9I.html

@andreyzavgorodniy7444

4 жыл бұрын

@@nkhitrov спасибо большое)

@feoktant

3 жыл бұрын

Спасибо за видео, пишу не на Питоне, но проблемы ровно те же в коде встречаю) Часто попадается код в CRUDах, где из контроллера вызывается Repository. По факту та же история что и с Model из View, правильно?

Есть ли ссылка на более подробное описание в примерах реализации services в django?

@t0digital

4 жыл бұрын

Ссылки нет. Думаю, разберём на живом примере как-нибудь

@nkhitrov

4 жыл бұрын

kzread.info/dash/bejne/q3tnvMaxcsWXn9I.html

Огромное спасибо. Я уже успел задуматься, почему view, когда там обрабатываются запросы. Твоё решение кажется супер крутым, спасибо. Конкретно в моем случае, очень поможет. Не мог бы ты или другие люди в коментах ответить на мои вопросы? Я реализую приложение для документооборота. 1) Имеется несколько должностей работников, для каждой описал отдельный модуль. Поскольку у работника может быть несколько ставок, сделал такую связь: User -> Worker -> WorkerPosition

@t0digital

4 жыл бұрын

Не смог понять структуру классов/таблиц и что за данные в них по описанию - надо вникать более глубоко, чтобы ответить на вопросы

Задача контроллера - превратить request в response. Все просто и понятно.

Алексей, а можете подробно рассказать как устроен Django изнутри? Как там с роутингом работать, как модели создавать, либо импортировать из готовых баз, как правильно писать шаблоны и вьюшки, как и где правильно писать бизнес-логику. Советы для начинающих, чтоб обойти подводные камни на этапе изучения фреймворка и представление о том что к чему уже складывалось в голове. А то вот сейчас столкнулся с кучей вопросов и проблем на этапе изучения (даже с роутингом не могу толком разобраться и логику всю во вьюшках пишу), сижу курю документацию днями и ночами, пытаясь понять что к чему)))

Не раз возвращаюсь к этому ролику) у тебя очень позитивные и полезные видео, так держать! :) Может подскажешь, что лучше использовать для вида приложения в веб: чистый css (scss) или bootstrap?) P.S. Сейчас перехожу с flask на django

@t0digital

Жыл бұрын

Если по-быстрому и особо не вникать, то фреймворки, а так лучше css изучить чистый, он сейчас модный и достаточно простой в использовании

Спасибо!

За такой видос, ссылку в ВК опубликовал. Спасибо

@t0digital

4 жыл бұрын

Спасибо!

Спасибо!!! Лайк

В очередной раз убеждаюсь, что все эти подходы типа mvc не имеют смысла в качестве инструкций. Да, есть models.py, где лежит список сущностей и порядок работы с ними. Никто не мешает, если файл раздулся или требуется переиспользование, вынести функцию наверх файла или в отдельный файл. Точно также никто не мешает, если views.py стал нечитабельно-огромным или нужно переиспользование, вынести именно эту логику в отдельный файл и импортировать его куда надо, когда это понадобилось. Но также нет ничего плохого в том, чтобы написать логику внутри views.py. Просто естественно всегда надо думать немного наперед, разделять и переиспользовать. А когда вы по инструкции придерживаетесь всяких стандартов, то лезть за двумя строками в какие-то сервисы - ну зачем? Код - это творчество. Хорошим кодом ценители восторгаются также, как и картиной, например. В живописи тоже куча техник и подходов, весьма четко описанных, творчества там ноль. А хорошие картины ведь часто получаются на стыках этих технологий, когда худохник не тупо их использует, а знает, когда лучше так, а когда - иначе, вот и тут также.

Спасибо за видео, ты молодец!

@t0digital

4 жыл бұрын

Спасибо!

Доступным языком, не плохо)

@t0digital

4 жыл бұрын

Спасибо

3:20 Сортировку массива перед показом можно в отображение запихнуть? (при условии что в бизнес модели этот массив отсортированный не используется)

@t0digital

4 жыл бұрын

Я думаю, что да, это может быть логикой отображения. Не все шаблонизаторы это поддерживают, поэтому можно перенести это в контроллер. Частые задачи контроллера это форматирование, сортировка данных, пришедших от модели, и затем уже передача их в отображение

@cyber-doge

4 жыл бұрын

@@t0digital Спасибо!

По поводу отсутствия в Django возможности обратиться к БД из шаблона: разве код {{ foo.bar_set.all }} в шаблоне не приведет к запросу?

Просто шикарно.

@t0digital

4 жыл бұрын

Спасибо!

однозначный лайк! Извините, Автор, забыл Ваше имя. Анонс круса будет?

Здравствуйте, я тоже пришел к такому выводу и всю бизнес логику выносил в файл (пакет если он разрастается) под названием utils. Потому что в представлениях совсем не то место, а модели сильно распухают и плохо тестируются потом. Это надо пройти на своем опыте(!). Интересно было бы взглянуть на структуру этого пакета у Вас

@MOVxR32

4 жыл бұрын

Название services мне нравится гораздо больше. Погуглил - это действительно очень распространенный подход а я дошел до него только после года фриланса и работы работы над приложениями за зарплалу. Как же многого мы (я) еще не знаем...

Я так и не научился по человечески писать код на PHP,, но мой велосипед потихоньку приходит к модели MVC :)

@t0digital

4 жыл бұрын

Вы на верном пути и это главное!

Во многих фреймворках новички пишут бизнес-логику в моделях, т. к. им кажется, что больше негде. Опытные люди обычно выносят бизнес-логику в сервисы, а в моделях остаётся только структура данных.

@bobobo500

4 жыл бұрын

Это вы про микросервисную архитектуру ?!

@sidorovich21101986

4 жыл бұрын

@@bobobo500 Нет. Под сервисами я подразумеваю вспомогательные классы.

А пример джанго проекта с правильной бизнес-логикой можешь показать, а то в итоге какая-то дыра... там писать нельзя, тут тоже нельзя, зато можно вон там в уголочке, но вот как это делать не совсем понятно(совсем непонятно)

@WorldCount

4 жыл бұрын

Так он же показал. Делаешь отдельный пакет и там строчишь бизнес-логику. Потом подтягиваешь её во views.

@gustaugutter9477

4 жыл бұрын

​@@caesarfatalhammer4449 я не говорил про бизнес. Я попросил показать практически правильное решение того, о чем он говорит. Потому что, как сказал автор, большинство пишет бизнес-логику в моделях или во вьюхах. Подхода, о котором он говорит, я не встречал ни в одном уроке, поэтому соответствующая просьба. Так что твой ядовитый высер здесь ни о чем...

@gustaugutter9477

4 жыл бұрын

@@WorldCount Ну он показал как это выглядит(как папочки лежать должны), а я прошу о тупом примере работы этих сервисов. Потому что мне непонятно зачем выводить в отдельный сервис, например, добавление товара в корзину, или оформление заказа, если мы говорим об интернет-магазине. Таким образом получится, что во вьюхе останется 2 строчки кода (вызов сервиса и return какие-то данные). Вот в этом вопрос. Зачем такое сильное дробление? Предполагаю, что в больших проектах оно необходимо. Я в таких не участвовал. Поэтому хочу услышать ответ от опытного человека, который занимается тем, что делится знаниями посредством своего ютуб канала. Зачем отдельный пакет с сервисами и почему это эффективнее, чем писать методы к моделям и писать БЛ во вьюхах.

@gustaugutter9477

4 жыл бұрын

@@MrBytmin Спасибо за развернутый комментарий. Действительно в видео об этом говорилось, но почему-то не уложилось по полочкам. После вашего ответа стало немного понятнее. Но все же посмотрев на код, было бы еще понятнее))

@7daysmma

4 жыл бұрын

"правильной бизнес-логикой" Для меня например загадка зачем тащить MVC в Джангу. Правильным скорее будет то, что по дефолту. А по дефолту в Джанге - MVT.

Спасибо за видео. Хотелось бы узнать, планируется ли раскрытие таких тем как Domain Driven Design, Test-Driven Development и т.п. ? Заранее спасибо за ответ.)

@t0digital

4 жыл бұрын

Да, обязательно будет

@nikzvonov2614

4 жыл бұрын

@@t0digital Отлично)

Cпасибо за объяснения MVC. Изучал Django по книжке Дронова и очень сильно раньше бесился, почему автор упорно называет вьюхи контроллерами. Теперь понимаю, откуда растут ноги. Интересно было бы узнать, чем руководствовались создатели Джанги, когда вводили такую архитектуру и нейминг.

@t0digital

4 жыл бұрын

Да, мне тоже интересно, почему так

@user-mg4no7xo6x

3 жыл бұрын

@@t0digital может потому что Django реализует не MVC а MVT архитектуру?)

@t0digital

3 жыл бұрын

@@user-mg4no7xo6x не суть вообще

Здравствуйте! Пишу свой первый проект и есть немного каши в голове. Если я создаю контроллер, который возвращает конкретную страницу участника блога с деталями, и в шаблоне во время использования template engine и обхода authors в цикле, использую {{ author.article_set.count }} то получается, что я делаю запрос в бд из шаблона, и это нарушение mvc(mtv) паттерна?

Расскажите про контроль версий для проектов (для файллв и для бд)?

@t0digital

4 жыл бұрын

про Git будет материал. Версионность БД в минимальном виде это механизм миграций в Django, аналогичный есть в других фреймворках

Классный ролик, но есть 1 замечание. К Django обычно применяется термин MVT (model-view-templates), а не MVC

@t0digital

4 жыл бұрын

Да, если быть точным, но это мало что меняет. Писать бизнес-логику в том слое, что Django называет View, нельзя. Ребятушки вон пишут (djbook.ru/ch05s02.html), что там-то и надо бизнес-логику писать, ай-яй, это нехорошо:)

@WorldCount

4 жыл бұрын

А urls.py что тогда такое? Не контроллер? Я как новичок спрашиваю. Models.py это тупо описание таблиц бд. Бизнес-логики там почти нет. Во views.py - бизнес-логика, модель по-факту. Templates - как раз вью. Urls.py - связующее звено между view и templates, типо контроллер, нет? Какое-то смещение выходит) Пи.Ся > Видео посмотрел, об этом кстати и говорят)

Очень крутое видео! Объяснил много моментов, на которые негде было найти ответы. Но один вопрос ещё остался: Model.objects.all() и подобные вызовы тоже выносить в сервисы? Если да, то как это делать правильно? Было бы очень круто, если бы ты сделал видео с наглядным примером как именно что либо выносится в отдельный слой!

@maksimangerman6238

Жыл бұрын

Я вообще все во вьюхах делал🤦🏻‍♂️ а оказывается, что это говнокод😁

@omka4580

10 ай бұрын

@@maksimangerman6238 жиза)

Какой у вас дополнительный монитор? Классный канал!

@t0digital

3 жыл бұрын

Спасибо! Это монитор LG 27" с type c 4к модель, не помню номер

Согласен.Помню писал сайт обьявлений - тупо делил на апсы без использования бизнес логики(Использовал только отдельные тулы).Недавно договорился заказчиком на саппорт сайта.Ну вот - поплыл в своем коде

Вот есть вопрос. Про модели в Джанго согласен полностью, как и вообще со всем видео, но... В одной книге, проверка пароля, определяется в классе модели, а вызов этого метода происходит в views.py, т.е. в модели. Выглядит вроде прилично. По опыту, можно так отступать, или лучше вывести это в отдельный класс? И про миксины хотелось бы узнать мнение. Если к примеру вывести часть бизнес-логики в миксин, не нарушит ли это MVC?

@t0digital

4 жыл бұрын

с миксинами надо быть аккуратненько, это множественное наследование, можно выстрелить себе в ногу случайно. Миксины должны быть очень маленькими и минималистичными, а бизнес-логика такой бывает редко

Forms & Signals, не? Хотя, можно и отдельный сервисный слой.

@t0digital

4 жыл бұрын

Сигналы это вообще ОЧЕНЬ спорное решение в джанго, дебажить это потом боль. У форм область применимости небольшая.

Спасибо

Я правильно понял. Что добавление товара в корзину лучше не делать во View приложения. А поручить это например api rest?

@t0digital

2 жыл бұрын

API REST не имеет никакого отношения к теме вопроса. Во View добавления товара в корзину быть не должно, View должен вызывать функции добавления в корзину, определенные не во View.

Неплохо, но упущено много важных моментов. Не всегда и не везде есть принципиальная возможность выносить всю логику за пределы view-метода. Как быть если нам нужно проверить атрибуты объекта ещё до момента инициализации сериализатора? Что если у нас имеется over-100500 полей и параметров, с которыми работает сервис? А если мы в одном запросе работаем с объектами разных типов, получится ли это сделать без затрагивания слоя представлений?

Сколько не читал/смотрел/изучал примеры 99% пихают логику в Views, что-то мелкое в методы класса модели, называя это вычисляемыми полями (если вывод информации), или в метод save если требуется что-то сделать с инстансом, но никто не выносит в отдельные "файлы". При этом в работе столкнулся с тем, что если "засунуть" все во View то начинается боль в определенном месте, и в итоге пришел к такому выводу: - сложная логика, т.е. логика затрагивающая N моделей и/или требующая расчета/анализа, т.е. действий над данными - отдельные модули с классами для работы с нужными моделями (проверки, логика, сохранение, обновление) Т.е. по сути тут даже логически придешь к выводу, что нужно вынести это куда-то иначе твоя вьюха или модель станет просто не читаемым куском г..на Пихать же все в модель верх безумства, на примере своей работы уже задумываюсь даже вычисляемые поля выносить с моделей, ибо 20 полей модели + 20 вычисляемых, которые частично могут затрагивать другие модели это печаль и простыня, а если туда еще запихнуть логику - тушите свет.

@t0digital

4 жыл бұрын

Спасибо, что поделились! Всё именно так и есть

Использовать сервисы внутри джанго аппликаций - хорошая идея. Но как тогда быть например с generic views или model serializers/forms? GenericView не может существовать без relation на django model. В ModelSerializer и ModelForm тоже самое. Более того - там есть методы create, update, save -уже точно не помню как они називаются, но не суть. Если бизнес логику вынести отдельно - то вышеперечисленные инструменты не очень подойдут. Этo сильные инструменти django и если ними не пользоватся тогда зачем django нужно, если есть например Flask?

@t0digital

4 жыл бұрын

Django не лучше и не хуже Flask, они просто разные. Во Flask вы накручиваете любые нужные инструменты сами, Django даёт вам готовый неплохо собранный каркас с ORM, миграциями, надстройками для тестов, формами, отличной админкой и тд. Что касается бизнес-логики и джанговых/DRF методов create/read/update - они могут быть и вызывать слой бизнес-логики (сервисов)

То есть в services пилить логику, а во views оставить только return render?

Расскажи про Flask