Архитектура ПО, MVC и бизнес-логика. Критика Django

[@slavchina_reviews]

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

[@t0digital]

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

[@xm4dn355x]

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

[@singirin]

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

[@t0digital]

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

[@МишаАлексеев-я1ч]

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

[@РодионСоловьев-к1ч]

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

[@ola_amirova]

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

[@TeppopucT]

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

[@canada946]

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

[@t0digital]

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

[@canada946]

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

[@ДанилЕфимов-г9п]

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

[@t0digital]

Спасибооо!

[@dmmeteo]

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

[@muratdautov7576]

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

[@nikolay1944]

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

[@wandos777]

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

[@vkh5864]

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

[@Geolimber]

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

[@t0digital]

Отлично!

[@maksimangerman6238]

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

[@maksimangerman6238]

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

[@Кантригоспел]

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

[@t0digital]

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

[@toomanof]

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

[@senatortre7326]

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

[@senatortre7326]

kzbin.info/www/bejne/r3iWi5eud8dkpdE многое поясняет данная лекция.

[@gregn834]

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

[@t0digital]

Отлично!

[@spair2k]

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

[@t0digital]

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

[@zamermen]

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

[@t0digital]

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

[@vladislavmikhailov]

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

[@k4m454k]

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

[@TheTruepikvic]

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

[@kosatchev]

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

[@zenovsergey]

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

[@xander-on-the-earth]

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

[@t0digital]

Спасибооо💪!

[@ILMIX007]

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

[@vladyslavnazarenko]

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

[@t0digital]

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

[@GrinRuslan]

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

[@t0digital]

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

[@Krasnolesye]

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

[@nikolaymatveychuk6145]

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

[@sivr5vs38]

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

[@nikolaymatveychuk6145]

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

[@sivr5vs38]

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

[@nikolaymatveychuk6145]

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

[@sivr5vs38]

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

[@mikhailfedorov4034]

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

[@vsbff]

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

[@АндрейРожнов-ш9к]

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

[@t0digital]

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

[@jonsnow8178]

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

[@zgrad2008]

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

[@ЕленаМ-ц2ъ]

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

[@dzianish6223]

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

[@MrVindor]

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

[@hackroute]

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

[@Кантригоспел]

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

[@t0digital]

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

[@Кантригоспел]

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

[@gustaugutter9477]

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

[@WorldCount]

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

[@gustaugutter9477]

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

[@gustaugutter9477]

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

[@gustaugutter9477]

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

[@7daysmma]

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

[@vrabosh]

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

[@eamarc]

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

[@daniilafendulov7401]

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

[@t0digital]

Отлично!

[@notrlt]

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

[@АртёмК-л7д]

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

[@КириллМеха]

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

[@t0digital]

Спасибо!

[@AlexBabinoff]

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

[@t0digital]

Отлично

[@ablyakimablyalimov8848]

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

[@MADAHAKO]

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

[@t0digital]

Спасибо!

[@МишаАлексеев-я1ч]

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

[@nilsen1879]

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

[@t0digital]

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

[@Sebasq31]

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

[@hovharoyan3262]

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

[@trtx1]

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

[@slava_po]

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

[@t0digital]

Спасибо!

[@b-o-t-l-y]

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

[@t0digital]

Спасибо 🙏

[@sergeyshevtsov5125]

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

[@sergafanasiev7956]

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

[@cyber-doge]

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

[@t0digital]

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

[@cyber-doge]

@@t0digital Спасибо!

[@MOVxR32]

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

[@MOVxR32]

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

[@vitalibirulia]

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

[@JustDoit-bl6pq]

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

[@t0digital]

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

[@nkhitrov]

kzbin.info/www/bejne/r3iWi5eud8dkpdE

[@DimiEG]

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

[@t0digital]

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

[@DimiEG]

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

[@t0digital]

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

[@t0digital]

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

[@DimiEG]

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

[@qazaqbalasy916]

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

[@ynxela]

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

[@ubuntuAndrew]

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

[@andreyzavgorodniy7444]

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

[@nkhitrov]

В этом докладе вроде были примеры. Собственно, весь доклад про это kzbin.info/www/bejne/r3iWi5eud8dkpdE

[@andreyzavgorodniy7444]

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

[@feoktant]

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

[@АлексейТертышников-и3т]

видео классное, но, мне, как начинающему программисту, хочется своими словами описать то, что понял/ не понял из видео. В видео вы говорите, что бизнес-логика - это работа с корзиной: вызвать из бд по определенному запросу, и пройтись циклом, это с одной стороны. С другой стороны, насколько я понял, вы говорите, что бизнес-логика - слой servises - это чисто запросы к БД с необходимой фильтрацией. Относится ли к бизнес-логике: посчитать количество заказов в корзине, посчитать сумму заказа, применить какую-то скидку на каждую позицию? Или это уже относится к контроллерам (меня тоже напрягает название view).

[@ДанькаЛобанов-у6ю]

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

[@sidorovich21101986]

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

[@bobobo500]

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

[@sidorovich21101986]

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

[@jtprogru_channel]

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

[@t0digital]

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

[@jtprogru_channel]

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

[@t0digital]

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

[@xm4dn355x]

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

[@kuziakivmarko]

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

[@t0digital]

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

[@qazaqbalasy916]

А где писать запросы в БД если не во view?

[@ForYouNegative]

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

[@t0digital]

Спасибо

[@nikolaisalikov1257]

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

[@t0digital]

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

[@0682797]

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

[@pchelonavtika]

3:12 думается мне, если рассматривать отображение в контексте интерфейса приложения, то как раз таки там есть ух какая логика! Так что если кто-то говорит что там нет логики, явно заблуждается!

[@t0digital]

да, конечно, просто это логика отображения - но она может быть сложной

[@yourownazog8069]

классная кружка в японском стиле =)

[@t0digital]

Спасибо:) нравится тоже:)

[@АлександрМельник-ч3ь]

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

[@t0digital]

_я правильно понял что его нужно оплачивать помесячно? (забыл оплатить и магазин не может принимать заказы?)_ Да, сервис платный, без денег не работает:) _как происходит добавление новых служб доставки?_ Что-то сложное - через нас, а свою простую курьерку или пункт выдачи можете добавить сами в личном кабинете. Modx модуля нет, интеграции под них соответственно тоже. Запросов на Modx большого количества тоже нет, так что не уверен, что будем делать в ближайшее время. Интегрировать всё на js не получится, информацию о доставке надо ведь сохранять в CMS. Плюс выгрузка заказов и тд. Полноценная интеграция это непросто.

[@АлександрМельник-ч3ь]

@@t0digital Спасибо, я видимо не совсем правильно понял суть. Считал, что это просто некий отдельный модуль, который будучи установлен на сайт работает обособленно и исключительно локально. Такие модули как правило имеют разовую фиксированную стоимость. А у Вас получается, что модуль это лишь некий клиент, работающий с вашим сервисом и данные хранятся на ваших серверах. Тогда понятно откуда стоимость в виде ежемесячной подписки. Удачи в его популяризации, выглядит эффектно и особенно порадовала приятная и понятная документация по api, что редко встретишь.

[@t0digital]

@@АлександрМельник-ч3ь спасибо! Да, мы храним все тарифы и данные у себя, обновляем их и позволяем гибко настраивать. Помимо гибкости настройки это даёт большой буст в скорости работы - API служб доставки медленные и ненадежные, отваливаются часто (привет СДЭК), мы это решаем как раз за счет хранения данных у себя

[@SuperBizon012]

Всегда нравились аргументы типа - "Это бред, это бред"

[@t0digital]

Очевидно мне тоже

[@richardclark4111]

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

[@tigranovakyan4913]

Оставь ссылку на клавиатуру))

[@MrDnovik]

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

[@SergMirny_yt]

Погодите. Я уточню для себя, если позволите. Модели в Джанго, да и не только в нем (например в Ларавеле тоже), по сути отвечают за коммуникацию с базой. То есть, что-то внести/извлечь в/из базы? Одновременно с этим, у разработчиков парадигмы MVC, есть пожелание, которое, по хорошему, является правилом - контроллеры должны быть худыми... И вот тут вопрос, как же писать бизнес логику? И как ее писать в модели? Если в Джанго модели содержат в себе, по сути, просто поля которые содержит база. Тут я допускаю, что я просто не образован а этом плане (по этому и спрашиваю), например как я делал в Ларавеле - создавал отдельные классы в отдельных файлах и к ним обращался из контроллеров, а в этих классах уже взаимодействовал с базой (честно, делал это посредством сырых запросов в БД, то есть, даже без моделей) и возвращал контроллеру данные для передачи во вьюху... Так как же правильно делать в джанге?

[@t0digital]

Про Лару не скажу, с ней не работал, но в Django как такового слоя для бизнес-логики не предусмотрено в стандартных слоях. Кто-то рекомендует писать бизнес-логику в моделях, но я не считаю это правильным. Модели - описание структуры данных для БД/ORM, это не лучшее место для бизнес-логики. Я рекомендую создавать модуль services.py и писать БЛ туда, или, если БЛ много, то создавать пакет services, и делать в нём несколько модулей (файлов) с бизнес логикой.

[@SergMirny_yt]

@@t0digital спасибо большое. По сути, как я понял это такой же подход как у меня в ларке был. То есть создаём отдельный файл с классами (если необходимо из несколько) и там уже занимаемся "развратом" с данными)) возвращаяя в views обработанные данные. Спасибо Вам большое. Вот, не примите как подхалимство, но Вы наверное один из не многих, если не единственный, настоящий практик в ютьюбе(это чувствуется), который действительно рассказывает как надо. За это Вам огромное спасибо от таких джунов как я)) Если позволите, вот просьба как, именно, от джуна, который не имеет коммерческого опыта (хотя писал несколько приложений и web в том числе), не могли бы вы на примере какого нибудь проекта показать как это происходит в коммерческой разработке. От момента, вот приходит человек на проект, ему дают репозиторий, он его клонирует, выполняет задачу свою, коммитит на ревью, потом, сливается в общий репозиторий... Этого маслята, типа меня, как раз не знают и не понимают до конца. И это пугает )))

[@michaelfilenko8598]

Лайк, если "Здаров, котаны" было лучше

[@ОлегВоронов-э2ц]

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

[@t0digital]

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

[@Tavda]

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

[@t0digital]

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

[@vbuoc]

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

[@t0digital]

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

[@touchdownscale]

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

[@t0digital]

Спасибо!

[@AndreyChursin]

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

[@t0digital]

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

[@ВладиславОрлов-ф4ц]

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

[@t0digital]

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

[@Орест-к9к]

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

[@t0digital]

@@Орест-к9к не суть вообще

[@JustForFun_Games]

А разве запросы к бд не должны быть в ДАО, к которому обращается слой бизнес логики?

[@jshuckbot]

А что у вас за монитор на стене?

[@t0digital]

Моник LG какой-то. Он на подъёмном столе стоит

[@Рустем-л2д]

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

[@t0digital]

Спасибо!

[@homaas7150]

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

[@t0digital]

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

[@ihorbilous7604]

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

[@t0digital]

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

[@dmitrytsmyh5971]

Секундочку ... Т.е. в services описана общая логика запросов в БД, которая подходит и к вебу и к DRF? Звучит конечно интересно, но не является ли это множителем кода? Вьюшки работают с реквестами, сессиями и делают (в лучшем случае) по 1 запросу в БД. АПИ, там формы и страницы отличаются от веба, и андроиды-разработчики могут слать тебе скопом всю инфу, когда им удобно. Хотя, конечно, это придирки.) Дайте, плиз, какую ссылочку на гитхабе, где services, объединяют бизнез логику АПИ и веба.

[@t0digital]

Принципиальной разница API и веба нет. Схема работы API - пришел запрос в контроллер (джанговый views), контроллер распарсил его, возможно проверил корректность данных в запросе, запросил данные в сервисах, получил их и вернул в JSON клиенту. Схема работы веба такая же, просто на последнем шаге данные вернутся не в JSON клиенту, а в template, который их вставит в HTML и клиенту улетит HTML с данными.

[@ПолинаБескоровайная-г3т]

А что насчет DRF? В документации DRF очень много примеров того, как во views происходят прямые обращения к БД. Что-то типа: class UsersList(ListAPIView): queryset = User.objects.all() serializer_class = UsersListSerializer Это же нарушение MVC, нет?

[@t0digital]

Drf часто провоцирует на плохой код, да

[@andreypetrov5204]

Например, такое это бизнес логика? Такое тоже стоит выносить в отдельный слой? obj_list = self.model_name.objects.all().prefetch_related \ (Prefetch('toolmove', queryset=ToolMove.objects.order_by('-date', '-id').select_related('to_supplier'))) filtered_obj_list = ToolFilter(request.GET, obj_list)

[@t0digital]

Получение данных с ORM - бизнес-логика. Работа с GET параметрами - не бизнес-логика. Контроллер получает данные из входных параметров HTTP запроса, возможно валидирует их (валидация может быть частью контроллера или частью бизнес-логики) и затем вызывает слой бизнес-логики, отправляя в него полученные на вход и возможно провалидированные параметры. Получает ответ от БЛ и использует его для формирования HTTP ответа.

[@andreypetrov5204]

@@t0digital Спасибо. Не часто отвечают на вопросы в видео годовалой давности. В общем надо мне довольно много кода править :)

[@ivanhumenyuk6054]

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

[@ВалерийКокорев-ч6т]

Здравствуйте. Вопрос мучает меня. Пишу MVC приложение на C#. Нужно получать записи с учётом пагинации, фильтров, сортировки и всё это в разных комбинациях. Не хочется плодить кучу методов для разных вариантов выборки данных в сервисе, да и выглядит это, как задачи контроллера. Как правильно решать такие ситуации? Давать доступ контроллеру к орм для выборки, или добавлять методы в сервис?

[@t0digital]

Привет! Не надо ходить в ORM из контроллера, эту логику надо выносить в отдельный слой 100%. Как именно на уровне бизнес логики её лучше сделать вопрос второй, но все фильтрации и подобное должны быть там. Сортировка данных на мой взгляд допустима в контроллере, но фильтры в отдельном слое.

[@ВалерийКокорев-ч6т]

@@t0digital Спасибо. Было устойчивое желание опустить слой бизнес логики, а тут ваше видео.

[@alvin_aliev]

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