Тема супер. После первого знакомства с джангой я как то неделю пытался найти в интернете куда же нужно пихать бизнес логику. Так и не нашёл кстати) Но пришёл к тому же способу как в видео
Отличное видео! Очень полезно и информативно. Теория ясна, теперь ждём видео с практикой модель-вью-контроллер. Не хватает таких видео, где всё архитектурно грамотно и красиво, чтобы понимать как оно происходит.
Диджитализируй! АйТи студия а ещё если можно, расскажите как можно использовать одно приложение Джанго (не проект) в нескольких проектах, если такое вообще возможно. Как наоборот сделать (один проект, много приложений) понятно :)
Вообще сами разработчики Джанго говорят что контроллеры в Джанго это скорей urls.py а бизнес логику рекомендуют писать в models.py. В компании которой я работаю сейчас, мы тоже используем подход с services & selectors(места для агрегации данных) и мы это унаследовали от Болгарский компании hacksoftware которая одна из первых описала стайлгайд для такого стиля архитектуры для Джанго;) и это подход достаточно удобен на практике)
Здравствуйте. Отличное видео. Слушать вас можно часами. Сам я работаю с Ruby и RoR. Недавно заинтересовался в джанге и сейчас уже делаю проекты и на RoR и на Джанге. Я был удивлен когда узнал, что в Джанге MVT архитектура. Действительно из-за этого код пишется то в view, то в моделях. Возможно изначально Джанга задумывалась не только как веб фреймворк. Поэтому здесь нет такого жёсткого разделения. В каждом проекте ты можешь тонко настроить всё под свои нужды. В рельсах хоть и MVC, но бизнес логику ты тоже пишешь в сервисах. Хотелось бы увидеть с вашей точки зрения топ проектов на Джанге на гитхабе с хорошим кодом. Спасибо.
Спасибо, отличная тема!!!) Если подытожить, в джанго советуешь делать: 1.модуль service - файлы (скрипты) с бизнес логикой (запросы к бд и другие работы с данными) 2. views.py - контроллер 3. Ну и шаблоны это понятно отображение (views из mvc) Так?)
Как же вовремя это видео, когда пошел на курс по джанго... Очень хочется делать красиво. Хотелось бы подробнее с технической части, взглянуть на структуру проекта. Плохо понятно со скриншота, ну папочки там какие-то, и что? django-service-objects юзать стоит? В дзене питона вон говорят, что проще - лучше и вообще главное, чтоб работало. Не все наслышаны о MVC (тем более очевидно, раз в каждом 1ом проекте такие косяки), стоит развить эту тему! Помог начать задавать правильные вопросы, спасибо!=)
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер - таким образом, что модификация каждого компонента может осуществляться независимо
БлагоДарю за такую замечательную подачу материала. Хотелось бы в роликах увидеть подробности, как правильно организовывать архитектуру кода при написании простого приложения (или отдельной функции бизнес-логики) соблюдая принципы DRY.
Здравствуйте! Пишу свой первый проект и есть немного каши в голове. Если я создаю контроллер, который возвращает конкретную страницу участника блога с деталями, и в шаблоне во время использования template engine и обхода authors в цикле, использую {{ author.article_set.count }} то получается, что я делаю запрос в бд из шаблона, и это нарушение mvc(mtv) паттерна?
Джавашные либы это Spring. Он из коробки даёт DI и некурильщик создает контроллер, ставит над ним аннотацию (в питоне это вроде декоратор) @Controller, создаёт интерфейс сервиса (без реализации), создаёт класс имплементирующий интерфейс сервиса и ставит над ним @Serivce. В классе контроллера создает поле типа интерфейса сервиса и ставит над ним аннотацию @Inject. Ну всё, дальше спринг делает магию DI при запуске.
Более того, должен быть слой контроллера, слой сервиса, слой репозитория, слой респонс-сервиса, и каждый друг для друга есть «чёрный ящик». Работаю по такой архитектуре со Spring и JavaEE (Jakarta EE), и все великолепно поддерживается. Однако, наговнокодить можно умудриться везде, если к тому душа лежит )
Как раз вовремя. Начал проект на джанго и мучался вопросом куда бизнес логику писать. Как раз начитался противоречивых советов, что во вьюху/модель писать. Потом посоветовали вообще рест фреймворк. Взрыв мозга. А тут всё по делу и понятно, спасибо.
Если загуглить "Django API Domains", то можно найти трактат, где ребята пошли ещё дальше, чем просто services. Я до сих пор жалею, что слишком поздно о нем узнал. Есть у меня несколько проектов, где такой подход избавил бы от множества костылей. Но переходить от ForeignKey к UUID - это очень трудоемкая задача для уже готового проекта.
выяснение/согласование тех задания - это один из пунктов архитектуры, в любой книге по архитектуре программирования это есть, последующие пункты так же важны как и этот, нет смысла не изучить всю архитектуру, если занимаешься программированием...
Когда проект небольшой, сложно читать бизнес в одном месте, а визуализацию в другом. Мне нравиться когда все в одном месте, но проектировка так, что это все кратко. Например: - Читаю базу корзины, и вывожу ее в нужную переменную которая потом отобразтся. - Удалить из корзины, удаляю и сразу отображаю.. file #1: db.insert(...); logicKorzina; viewBar += '' file #2: db.del(...); logicKorzina; viewBar += ''
В очередной раз убеждаюсь, что все эти подходы типа mvc не имеют смысла в качестве инструкций. Да, есть models.py, где лежит список сущностей и порядок работы с ними. Никто не мешает, если файл раздулся или требуется переиспользование, вынести функцию наверх файла или в отдельный файл. Точно также никто не мешает, если views.py стал нечитабельно-огромным или нужно переиспользование, вынести именно эту логику в отдельный файл и импортировать его куда надо, когда это понадобилось. Но также нет ничего плохого в том, чтобы написать логику внутри views.py. Просто естественно всегда надо думать немного наперед, разделять и переиспользовать. А когда вы по инструкции придерживаетесь всяких стандартов, то лезть за двумя строками в какие-то сервисы - ну зачем? Код - это творчество. Хорошим кодом ценители восторгаются также, как и картиной, например. В живописи тоже куча техник и подходов, весьма четко описанных, творчества там ноль. А хорошие картины ведь часто получаются на стыках этих технологий, когда худохник не тупо их использует, а знает, когда лучше так, а когда - иначе, вот и тут также.
В отображении не должно быть логики - да, обычно когда такое говорят, имеют ввиду именно бизнес логику :) Это такое сокращение, которое обычно воспринимается как очевидное. Контроллер плохо называть клеем между (моделями) бизнес логикой и представлениями (отображением). У контроллера есть одна основная задача - обработать запрос. То есть ему надо принять решение о том, что хочет пользователь, выполнить нужные действия, и показать пользователю ответ. Иначе, если бы контроллер был клеем между моделями и представлениями, то по данному шаблону было бы запрещено отправлять модели с данными в представления, а нужно было бы их разбирать на массивы и отправлять только массивы. В контроллере запрещена работа с БД через 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, а с чистыми моделями, потому что в данном случае получается, что данные системы находятся не в базе, а над уровнем базы, следовательно нам придётся винтить ещё и прослойку репозиториев (в которых теперь будут инкапулированы активрекорды и модели/формы для работы с другими каналами).
Здравствуйте, я тоже пришел к такому выводу и всю бизнес логику выносил в файл (пакет если он разрастается) под названием utils. Потому что в представлениях совсем не то место, а модели сильно распухают и плохо тестируются потом. Это надо пройти на своем опыте(!). Интересно было бы взглянуть на структуру этого пакета у Вас
Название services мне нравится гораздо больше. Погуглил - это действительно очень распространенный подход а я дошел до него только после года фриланса и работы работы над приложениями за зарплалу. Как же многого мы (я) еще не знаем...
Неплохо, но упущено много важных моментов. Не всегда и не везде есть принципиальная возможность выносить всю логику за пределы view-метода. Как быть если нам нужно проверить атрибуты объекта ещё до момента инициализации сериализатора? Что если у нас имеется over-100500 полей и параметров, с которыми работает сервис? А если мы в одном запросе работаем с объектами разных типов, получится ли это сделать без затрагивания слоя представлений?
А пример джанго проекта с правильной бизнес-логикой можешь показать, а то в итоге какая-то дыра... там писать нельзя, тут тоже нельзя, зато можно вон там в уголочке, но вот как это делать не совсем понятно(совсем непонятно)
@@caesarfatalhammer я не говорил про бизнес. Я попросил показать практически правильное решение того, о чем он говорит. Потому что, как сказал автор, большинство пишет бизнес-логику в моделях или во вьюхах. Подхода, о котором он говорит, я не встречал ни в одном уроке, поэтому соответствующая просьба. Так что твой ядовитый высер здесь ни о чем...
@@WorldCount Ну он показал как это выглядит(как папочки лежать должны), а я прошу о тупом примере работы этих сервисов. Потому что мне непонятно зачем выводить в отдельный сервис, например, добавление товара в корзину, или оформление заказа, если мы говорим об интернет-магазине. Таким образом получится, что во вьюхе останется 2 строчки кода (вызов сервиса и return какие-то данные). Вот в этом вопрос. Зачем такое сильное дробление? Предполагаю, что в больших проектах оно необходимо. Я в таких не участвовал. Поэтому хочу услышать ответ от опытного человека, который занимается тем, что делится знаниями посредством своего ютуб канала. Зачем отдельный пакет с сервисами и почему это эффективнее, чем писать методы к моделям и писать БЛ во вьюхах.
@@MrBytmin Спасибо за развернутый комментарий. Действительно в видео об этом говорилось, но почему-то не уложилось по полочкам. После вашего ответа стало немного понятнее. Но все же посмотрев на код, было бы еще понятнее))
"правильной бизнес-логикой" Для меня например загадка зачем тащить MVC в Джангу. Правильным скорее будет то, что по дефолту. А по дефолту в Джанге - MVT.
Недавно начал смотреть Django просто для расширения кругозора. Было странно видеть разделение models, view, templates, кроме того, почему в каждом из файлов содержится сразу несколько классов, это ведь неудобно? Далее меня удивило то, что в моделях должна содержатся вся бизнес логика + логика работы с БД. По крайней мере такое впечатление складывается когда смотришь документацию и некоторые проекты на github. Со слов автора видео понял что так делают не все, что радует. По поводу бизнес логики, я бы вынес ее в отдельное место и назвал бы это Domain, Services как по мне это больше служебные классы. Для запросов в БД есть паттерн Repository, для более сложных случаев можно использовать Specification. Модели в данном случае оставить просто как маппинг на таблицы БД. К слову, например в том же Symfony PHP фреймворке все организовано куда интересней.
Во многих фреймворках новички пишут бизнес-логику в моделях, т. к. им кажется, что больше негде. Опытные люди обычно выносят бизнес-логику в сервисы, а в моделях остаётся только структура данных.
Очень правильное видео, побольше бы таких. Стараюсь выносить логику в utils, не расширяя модели и контроллеры, но есть один очень непонятный момент в этом. 1) Джанга, как и DRF, содержит в контроллерах методы в стиле get_queryset и т.д., которые обращаются к модели и БД. Разве это ок? Конечно, можно заставить эти методы работать через сервисы, но насколько это практично, переопределять метод получения кверисета через сервис, дополнительно писать этот сервис? (Вариант с товарами надуман, т.к. там явно будет много логики, но, думаю, посыл понятен). 2) Пагинация - тоже вроде как бизнес логика, но в контроллере смотрится весьма гармонично. Что с ней? 3) Сериалайзеры - что делать с ними? Они неплохо смотрятся как "входной шлюз" для данных, которые мы получили в реквесте. Тоже их в сервис? 4) И сколько потом будет таких сервисов? Не получится ли какая-то каша, если для каждого чиха будет сервис? 5) Менеджеры - стоит ли вообще писать кастомы? Иногда удобно, но для себя пока не решил. В последнее время очень много задумываюсь над архитектурой и пробую выносить логику в сервисы, но озвученные выше вопросы не дают покоя.
Спасибо за видео, пишу не на Питоне, но проблемы ровно те же в коде встречаю) Часто попадается код в CRUDах, где из контроллера вызывается Repository. По факту та же история что и с Model из View, правильно?
Случайно набрёл на Ваш канал. Понравились видео по Vim, так как сам являюсь его горячим поклонником после Emacs, и по tmux. Особенно как их объединить для разработки. По MVC тоже понравилось, хоть с этой темой был знаком и ранее. Про Rust ваша фраза повеселила. Сам являюсь поклонником Rust и Golang. В них как раз нет классов и классам объявлен бой. Хотелось бы послушать рассуждения на эту тему или что нибудь по языку Rust. Python недолюбливаю. Относительно минимализма и vim с Вами полностью согласен. Стараюсь IDE не использовать совсем и работать в консоли. Спасибо и удачи каналу.
Да, интересно посмотреть по Golang. К тому же в Vim есть плагины для работы с этим языком. Впечатляет как вы управляетесь с Python. Не совсем понятно как вы его используете в проектах. Это или скрипты, которые обрабатывают данные, или WEB приложения на Python?
Golang для сетевых приложений очень хорош. В Python мне не нравится, что невозможно защитить код программы при передаче заказчику, что не всегда удобно или приходится шаманить с обёртками. Golang язык компилируемый. Также в Python табы управляют логикой программы. Да, код без скобок и точек с запятыми выглядит чище, но ошибки в отступе строк приводят к ошибкам в исполнении интерпретатором. С другой стороны конечно в Python очень много библиотек.
видео классное, но, мне, как начинающему программисту, хочется своими словами описать то, что понял/ не понял из видео. В видео вы говорите, что бизнес-логика - это работа с корзиной: вызвать из бд по определенному запросу, и пройтись циклом, это с одной стороны. С другой стороны, насколько я понял, вы говорите, что бизнес-логика - слой servises - это чисто запросы к БД с необходимой фильтрацией. Относится ли к бизнес-логике: посчитать количество заказов в корзине, посчитать сумму заказа, применить какую-то скидку на каждую позицию? Или это уже относится к контроллерам (меня тоже напрягает название view).
Мне понравилось решение в фреймворке fastAPI, там например вынесли бизнес-логику в отдельный модуль, в доке у них CRUD так выделили. Конечно добавляется ещё один слой, но выглядит масштабируемо и упорядоченно. В джанге, почему-то, в доке такого не показывают.
по поводу модуля доставки вашего есть пару вопросов. - я правильно понял что его нужно оплачивать помесячно? (забыл оплатить и магазин не может принимать заказы?) - как происходит добавление новых служб доставки? (это делает уже тот кто приобрел программу? К примеру недавно мне пришлось делать интеграцию со службой доставки Стриж, и по-моему ее нет в списке вашего модуля. Или же в ежемесячную плату входят и любые доработки?) - для небольших магазинов я использую CMS MODx и не вижу ее в списке поддерживаемых. Пошел почитать как происходит интеграция и вижу что она на js. Каждая CMSка как правило уже содержит свои инструменты для оформления заказов, расчета стоимости и так далее. Каким образом информация о заказе, оформленном через ваш модуль будет взаимодействовать с уже имеющимися в MODx сущностями заказа, статусами состояния заказа и так далее? (при учете что как такого api у modx для решения этих задач нет) ну и плюс тот же вопрос - доработка модуля под конкретную задачу уже входит в ежемесячную сумму? Спасибо.
_я правильно понял что его нужно оплачивать помесячно? (забыл оплатить и магазин не может принимать заказы?)_ Да, сервис платный, без денег не работает:) _как происходит добавление новых служб доставки?_ Что-то сложное - через нас, а свою простую курьерку или пункт выдачи можете добавить сами в личном кабинете. Modx модуля нет, интеграции под них соответственно тоже. Запросов на Modx большого количества тоже нет, так что не уверен, что будем делать в ближайшее время. Интегрировать всё на js не получится, информацию о доставке надо ведь сохранять в CMS. Плюс выгрузка заказов и тд. Полноценная интеграция это непросто.
@@t0digital Спасибо, я видимо не совсем правильно понял суть. Считал, что это просто некий отдельный модуль, который будучи установлен на сайт работает обособленно и исключительно локально. Такие модули как правило имеют разовую фиксированную стоимость. А у Вас получается, что модуль это лишь некий клиент, работающий с вашим сервисом и данные хранятся на ваших серверах. Тогда понятно откуда стоимость в виде ежемесячной подписки. Удачи в его популяризации, выглядит эффектно и особенно порадовала приятная и понятная документация по api, что редко встретишь.
@@АлександрМельник-ч3ь спасибо! Да, мы храним все тарифы и данные у себя, обновляем их и позволяем гибко настраивать. Помимо гибкости настройки это даёт большой буст в скорости работы - API служб доставки медленные и ненадежные, отваливаются часто (привет СДЭК), мы это решаем как раз за счет хранения данных у себя
блин. Ну про Джангу прям молодец! Но есть вопрос. У Вас слой сервисов работает по принципу паттерна репозиторий? (для того, чтобы достать все заказы к примеру вы используете методы модели или так же делаете прослойку этих методов в сервисном слое?)
Например, такое это бизнес логика? Такое тоже стоит выносить в отдельный слой? 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)
Получение данных с ORM - бизнес-логика. Работа с GET параметрами - не бизнес-логика. Контроллер получает данные из входных параметров HTTP запроса, возможно валидирует их (валидация может быть частью контроллера или частью бизнес-логики) и затем вызывает слой бизнес-логики, отправляя в него полученные на вход и возможно провалидированные параметры. Получает ответ от БЛ и использует его для формирования HTTP ответа.
Cпасибо за объяснения MVC. Изучал Django по книжке Дронова и очень сильно раньше бесился, почему автор упорно называет вьюхи контроллерами. Теперь понимаю, откуда растут ноги. Интересно было бы узнать, чем руководствовались создатели Джанги, когда вводили такую архитектуру и нейминг.
Я думаю, что да, это может быть логикой отображения. Не все шаблонизаторы это поддерживают, поэтому можно перенести это в контроллер. Частые задачи контроллера это форматирование, сортировка данных, пришедших от модели, и затем уже передача их в отображение
API REST не имеет никакого отношения к теме вопроса. Во View добавления товара в корзину быть не должно, View должен вызывать функции добавления в корзину, определенные не во View.
Сделай пожалуйста видос про выбор лицензии проекта при создании репозитори на гитхабе. в чём между ними различия и какую для какого проекта лучше выбрать.
Погодите. Я уточню для себя, если позволите. Модели в Джанго, да и не только в нем (например в Ларавеле тоже), по сути отвечают за коммуникацию с базой. То есть, что-то внести/извлечь в/из базы? Одновременно с этим, у разработчиков парадигмы MVC, есть пожелание, которое, по хорошему, является правилом - контроллеры должны быть худыми... И вот тут вопрос, как же писать бизнес логику? И как ее писать в модели? Если в Джанго модели содержат в себе, по сути, просто поля которые содержит база. Тут я допускаю, что я просто не образован а этом плане (по этому и спрашиваю), например как я делал в Ларавеле - создавал отдельные классы в отдельных файлах и к ним обращался из контроллеров, а в этих классах уже взаимодействовал с базой (честно, делал это посредством сырых запросов в БД, то есть, даже без моделей) и возвращал контроллеру данные для передачи во вьюху... Так как же правильно делать в джанге?
Про Лару не скажу, с ней не работал, но в Django как такового слоя для бизнес-логики не предусмотрено в стандартных слоях. Кто-то рекомендует писать бизнес-логику в моделях, но я не считаю это правильным. Модели - описание структуры данных для БД/ORM, это не лучшее место для бизнес-логики. Я рекомендую создавать модуль services.py и писать БЛ туда, или, если БЛ много, то создавать пакет services, и делать в нём несколько модулей (файлов) с бизнес логикой.
@@t0digital спасибо большое. По сути, как я понял это такой же подход как у меня в ларке был. То есть создаём отдельный файл с классами (если необходимо из несколько) и там уже занимаемся "развратом" с данными)) возвращаяя в views обработанные данные. Спасибо Вам большое. Вот, не примите как подхалимство, но Вы наверное один из не многих, если не единственный, настоящий практик в ютьюбе(это чувствуется), который действительно рассказывает как надо. За это Вам огромное спасибо от таких джунов как я)) Если позволите, вот просьба как, именно, от джуна, который не имеет коммерческого опыта (хотя писал несколько приложений и web в том числе), не могли бы вы на примере какого нибудь проекта показать как это происходит в коммерческой разработке. От момента, вот приходит человек на проект, ему дают репозиторий, он его клонирует, выполняет задачу свою, коммитит на ревью, потом, сливается в общий репозиторий... Этого маслята, типа меня, как раз не знают и не понимают до конца. И это пугает )))
Відео годнота! Спасибо Можете снять ролик где более подробно расскажите о создание правильной архитектуры с джанго на каких то близких к реалиям примерах?
Согласен.Помню писал сайт обьявлений - тупо делил на апсы без использования бизнес логики(Использовал только отдельные тулы).Недавно договорился заказчиком на саппорт сайта.Ну вот - поплыл в своем коде
А что насчет DRF? В документации DRF очень много примеров того, как во views происходят прямые обращения к БД. Что-то типа: class UsersList(ListAPIView): queryset = User.objects.all() serializer_class = UsersListSerializer Это же нарушение MVC, нет?
Приветствую! 1. Огромное спасибо за контент! Всегда приятно смотреть и слушать! 2. Можно ли получить пример по данному видео?! Хотелось бы наглядно посмотреть на организацию и логику распределения функций/классов/etc...
Диджитализируй! АйТи студия я понял сразу какой это проект :) Поэтому и попросил что-то на коленке - петпроджект какой-то изобрести с той структурой, которую описываете. Собственно говоря меня именно этот момент все время тормозит в Джанго 😩
Использовать сервисы внутри джанго аппликаций - хорошая идея. Но как тогда быть например с generic views или model serializers/forms? GenericView не может существовать без relation на django model. В ModelSerializer и ModelForm тоже самое. Более того - там есть методы create, update, save -уже точно не помню как они називаются, но не суть. Если бизнес логику вынести отдельно - то вышеперечисленные инструменты не очень подойдут. Этo сильные инструменти django и если ними не пользоватся тогда зачем django нужно, если есть например Flask?
Django не лучше и не хуже Flask, они просто разные. Во Flask вы накручиваете любые нужные инструменты сами, Django даёт вам готовый неплохо собранный каркас с ORM, миграциями, надстройками для тестов, формами, отличной админкой и тд. Что касается бизнес-логики и джанговых/DRF методов create/read/update - они могут быть и вызывать слой бизнес-логики (сервисов)
Секундочку ... Т.е. в services описана общая логика запросов в БД, которая подходит и к вебу и к DRF? Звучит конечно интересно, но не является ли это множителем кода? Вьюшки работают с реквестами, сессиями и делают (в лучшем случае) по 1 запросу в БД. АПИ, там формы и страницы отличаются от веба, и андроиды-разработчики могут слать тебе скопом всю инфу, когда им удобно. Хотя, конечно, это придирки.) Дайте, плиз, какую ссылочку на гитхабе, где services, объединяют бизнез логику АПИ и веба.
Принципиальной разница API и веба нет. Схема работы API - пришел запрос в контроллер (джанговый views), контроллер распарсил его, возможно проверил корректность данных в запросе, запросил данные в сервисах, получил их и вернул в JSON клиенту. Схема работы веба такая же, просто на последнем шаге данные вернутся не в JSON клиенту, а в template, который их вставит в HTML и клиенту улетит HTML с данными.
Огромное спасибо. Я уже успел задуматься, почему view, когда там обрабатываются запросы. Твоё решение кажется супер крутым, спасибо. Конкретно в моем случае, очень поможет. Не мог бы ты или другие люди в коментах ответить на мои вопросы? Я реализую приложение для документооборота. 1) Имеется несколько должностей работников, для каждой описал отдельный модуль. Поскольку у работника может быть несколько ставок, сделал такую связь: User -> Worker -> WorkerPosition
Здравствуйте. Вопрос мучает меня. Пишу MVC приложение на C#. Нужно получать записи с учётом пагинации, фильтров, сортировки и всё это в разных комбинациях. Не хочется плодить кучу методов для разных вариантов выборки данных в сервисе, да и выглядит это, как задачи контроллера. Как правильно решать такие ситуации? Давать доступ контроллеру к орм для выборки, или добавлять методы в сервис?
Привет! Не надо ходить в ORM из контроллера, эту логику надо выносить в отдельный слой 100%. Как именно на уровне бизнес логики её лучше сделать вопрос второй, но все фильтрации и подобное должны быть там. Сортировка данных на мой взгляд допустима в контроллере, но фильтры в отдельном слое.
Сколько не читал/смотрел/изучал примеры 99% пихают логику в Views, что-то мелкое в методы класса модели, называя это вычисляемыми полями (если вывод информации), или в метод save если требуется что-то сделать с инстансом, но никто не выносит в отдельные "файлы". При этом в работе столкнулся с тем, что если "засунуть" все во View то начинается боль в определенном месте, и в итоге пришел к такому выводу: - сложная логика, т.е. логика затрагивающая N моделей и/или требующая расчета/анализа, т.е. действий над данными - отдельные модули с классами для работы с нужными моделями (проверки, логика, сохранение, обновление) Т.е. по сути тут даже логически придешь к выводу, что нужно вынести это куда-то иначе твоя вьюха или модель станет просто не читаемым куском г..на Пихать же все в модель верх безумства, на примере своей работы уже задумываюсь даже вычисляемые поля выносить с моделей, ибо 20 полей модели + 20 вычисляемых, которые частично могут затрагивать другие модели это печаль и простыня, а если туда еще запихнуть логику - тушите свет.
Вот есть вопрос. Про модели в Джанго согласен полностью, как и вообще со всем видео, но... В одной книге, проверка пароля, определяется в классе модели, а вызов этого метода происходит в views.py, т.е. в модели. Выглядит вроде прилично. По опыту, можно так отступать, или лучше вывести это в отдельный класс? И про миксины хотелось бы узнать мнение. Если к примеру вывести часть бизнес-логики в миксин, не нарушит ли это MVC?
с миксинами надо быть аккуратненько, это множественное наследование, можно выстрелить себе в ногу случайно. Миксины должны быть очень маленькими и минималистичными, а бизнес-логика такой бывает редко
Спасибо за видео. Хотелось бы узнать, планируется ли раскрытие таких тем как Domain Driven Design, Test-Driven Development и т.п. ? Заранее спасибо за ответ.)
Не раз возвращаюсь к этому ролику) у тебя очень позитивные и полезные видео, так держать! :) Может подскажешь, что лучше использовать для вида приложения в веб: чистый css (scss) или bootstrap?) P.S. Сейчас перехожу с flask на django
Очень крутое видео! Объяснил много моментов, на которые негде было найти ответы. Но один вопрос ещё остался: Model.objects.all() и подобные вызовы тоже выносить в сервисы? Если да, то как это делать правильно? Было бы очень круто, если бы ты сделал видео с наглядным примером как именно что либо выносится в отдельный слой!
Какой же душевный у тебя контент. Как будто с корешем на кухне болтаю. Мне лично очень заходит такой подход, удачи в развитии канала!
Спасибо, очень приятно!
Тут сложно не согласиться)
Тема супер. После первого знакомства с джангой я как то неделю пытался найти в интернете куда же нужно пихать бизнес логику. Так и не нашёл кстати) Но пришёл к тому же способу как в видео
@@singirin отлично! Странно, что Django не даёт нормальных рекомендаций в своей же доке
@@t0digital Да, отдельный респект за это, никогда так не было приятно слушать материал
Такого понятного объяснения MVC я ещё нигде не встречал
Уже 4 раз пересматриваю и возвращаюсь к этому видео, 20 минут концентрированной, крутой информации! Спасибо!
Очень полезно!
Был бы тех диром, заставил бы всех джанговодов посмотреть этот ролик.
Спасибо
Отличное видео! Очень полезно и информативно. Теория ясна, теперь ждём видео с практикой модель-вью-контроллер. Не хватает таких видео, где всё архитектурно грамотно и красиво, чтобы понимать как оно происходит.
Обязательно будет живой пример. Спасибо!
Диджитализируй! АйТи студия а ещё если можно, расскажите как можно использовать одно приложение Джанго (не проект) в нескольких проектах, если такое вообще возможно. Как наоборот сделать (один проект, много приложений) понятно :)
Так бы и сидел все время и слушал ваше объяснение. Очень интересно объясняете. Спасибо!
Спасибооо!
Вообще сами разработчики Джанго говорят что контроллеры в Джанго это скорей urls.py а бизнес логику рекомендуют писать в models.py. В компании которой я работаю сейчас, мы тоже используем подход с services & selectors(места для агрегации данных) и мы это унаследовали от Болгарский компании hacksoftware которая одна из первых описала стайлгайд для такого стиля архитектуры для Джанго;) и это подход достаточно удобен на практике)
Здравствуйте. Отличное видео. Слушать вас можно часами. Сам я работаю с Ruby и RoR. Недавно заинтересовался в джанге и сейчас уже делаю проекты и на RoR и на Джанге. Я был удивлен когда узнал, что в Джанге MVT архитектура. Действительно из-за этого код пишется то в view, то в моделях. Возможно изначально Джанга задумывалась не только как веб фреймворк. Поэтому здесь нет такого жёсткого разделения. В каждом проекте ты можешь тонко настроить всё под свои нужды. В рельсах хоть и MVC, но бизнес логику ты тоже пишешь в сервисах.
Хотелось бы увидеть с вашей точки зрения топ проектов на Джанге на гитхабе с хорошим кодом. Спасибо.
Единственный канал, где меня с экрана называли "Котаном". раньше......
Да, хороший был канал 😊
Да, что с котанами?
Спасибо, отличная тема!!!)
Если подытожить, в джанго советуешь делать:
1.модуль service - файлы (скрипты) с бизнес логикой (запросы к бд и другие работы с данными)
2. views.py - контроллер
3. Ну и шаблоны это понятно отображение (views из mvc)
Так?)
Да, и models.py это ORM классы и возможно совсем чуть-чуть бизнес логики
Как же вовремя это видео, когда пошел на курс по джанго... Очень хочется делать красиво. Хотелось бы подробнее с технической части, взглянуть на структуру проекта. Плохо понятно со скриншота, ну папочки там какие-то, и что?
django-service-objects юзать стоит?
В дзене питона вон говорят, что проще - лучше и вообще главное, чтоб работало.
Не все наслышаны о MVC (тем более очевидно, раз в каждом 1ом проекте такие косяки), стоит развить эту тему! Помог начать задавать правильные вопросы, спасибо!=)
ruclips.net/video/yG3ZdxBb1oo/видео.html
многое поясняет данная лекция.
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер - таким образом, что модификация каждого компонента может осуществляться независимо
БлагоДарю за такую замечательную подачу материала. Хотелось бы в роликах увидеть подробности, как правильно организовывать архитектуру кода при написании простого приложения (или отдельной функции бизнес-логики) соблюдая принципы DRY.
покажу как-нибудь в живом примере, да!
На самом деле стало понятно, как MVC укладывается в django ) а то поназывали там views это контроллер... бр, спасибо, что разъяснили!
Давно сам задумывался о данном вопросе в Django. Сколько раз этот момент обсуждали с коллегами. Мы всю бизнес-логику выносим в фасады.
Здравствуйте!
Пишу свой первый проект и есть немного каши в голове. Если я создаю контроллер, который возвращает конкретную страницу участника блога с деталями, и в шаблоне во время использования template engine и обхода authors в цикле, использую {{ author.article_set.count }} то получается, что я делаю запрос в бд из шаблона, и это нарушение mvc(mtv) паттерна?
Джавашные либы это Spring. Он из коробки даёт DI и некурильщик создает контроллер, ставит над ним аннотацию (в питоне это вроде декоратор) @Controller, создаёт интерфейс сервиса (без реализации), создаёт класс имплементирующий интерфейс сервиса и ставит над ним @Serivce. В классе контроллера создает поле типа интерфейса сервиса и ставит над ним аннотацию @Inject. Ну всё, дальше спринг делает магию DI при запуске.
На восьмой минуте понял, что ничего не понятно, но, очень интересно. В любом случае, спасибо, Котан!
Кстати, давно уже задавался вопросом, где же в джанге бизнес прикручивать. Теперь знаю. Как раз вовремя видео подошло! Спасибо!
Отлично!
Спасибо за четкое, понятное объяснение. Молодца
Более того, должен быть слой контроллера, слой сервиса, слой репозитория, слой респонс-сервиса, и каждый друг для друга есть «чёрный ящик». Работаю по такой архитектуре со Spring и JavaEE (Jakarta EE), и все великолепно поддерживается. Однако, наговнокодить можно умудриться везде, если к тому душа лежит )
Как раз вовремя. Начал проект на джанго и мучался вопросом куда бизнес логику писать. Как раз начитался противоречивых советов, что во вьюху/модель писать. Потом посоветовали вообще рест фреймворк. Взрыв мозга.
А тут всё по делу и понятно, спасибо.
Отлично!
Лайк, на 1000% согласен! И про нейминг и про вопрос - где писать бизнес логику в Django
Январь 2023 года. И Вы открыли мне глаза) спасибо Вам!)
upd: И действительно очень ламповые и приятные выпуски.
Спасибо, лайк. Жду новых видео про архитектуру и паттерны
Спасибо, очень доступно объясняешь, кажется я начал кое что понимать)
Отлично, рад, что полезно!
Здравствуйте спасибо за разъяснение!Подскажите пожалуйста есть пример кода на джанго которое можно посмотреть )
Спасибо, хорошо, что у тебя посмотрел, чтобы как говорится, сразу правильно делать, а не переучиваться потом )
Если загуглить "Django API Domains", то можно найти трактат, где ребята пошли ещё дальше, чем просто services.
Я до сих пор жалею, что слишком поздно о нем узнал. Есть у меня несколько проектов, где такой подход избавил бы от множества костылей.
Но переходить от ForeignKey к UUID - это очень трудоемкая задача для уже готового проекта.
а перевод на русский язык есть трактата? или это считается нонсенс
выяснение/согласование тех задания - это один из пунктов архитектуры, в любой книге по архитектуре программирования это есть, последующие пункты так же важны как и этот, нет смысла не изучить всю архитектуру, если занимаешься программированием...
Когда проект небольшой, сложно читать бизнес в одном месте, а визуализацию в другом.
Мне нравиться когда все в одном месте, но проектировка так, что это все кратко.
Например:
- Читаю базу корзины, и вывожу ее в нужную переменную которая потом отобразтся.
- Удалить из корзины, удаляю и сразу отображаю..
file #1: db.insert(...); logicKorzina; viewBar += ''
file #2: db.del(...); logicKorzina; viewBar += ''
Отличный канал! Суперская подача материала! Высокий уровень! Автору -- респект, котанам -- привет!
Спасибооо💪!
Отличная лекция получилась, спасибо.
Спасибо!
Большое спасибо за видео. Было очень интересно и с именованием и хранением в services было ново и полезно.
Отлично! Рад, что полезно
Задача контроллера - превратить request в response. Все просто и понятно.
В очередной раз убеждаюсь, что все эти подходы типа mvc не имеют смысла в качестве инструкций. Да, есть models.py, где лежит список сущностей и порядок работы с ними. Никто не мешает, если файл раздулся или требуется переиспользование, вынести функцию наверх файла или в отдельный файл. Точно также никто не мешает, если views.py стал нечитабельно-огромным или нужно переиспользование, вынести именно эту логику в отдельный файл и импортировать его куда надо, когда это понадобилось. Но также нет ничего плохого в том, чтобы написать логику внутри views.py. Просто естественно всегда надо думать немного наперед, разделять и переиспользовать. А когда вы по инструкции придерживаетесь всяких стандартов, то лезть за двумя строками в какие-то сервисы - ну зачем? Код - это творчество. Хорошим кодом ценители восторгаются также, как и картиной, например. В живописи тоже куча техник и подходов, весьма четко описанных, творчества там ноль. А хорошие картины ведь часто получаются на стыках этих технологий, когда худохник не тупо их использует, а знает, когда лучше так, а когда - иначе, вот и тут также.
Спасибо! Настолько все очевидно и логично, что даже странно, что кто то делает иначе!!!
странно, но факт:)
Спасибо за видео! Хотелось бы увидеть пример, где "плохо", а где "хорошо"
Посмотрите код ревью, несколько видео есть на канале
Расскажи, пожалуйста, в отдельном видосе как ты проектируешь структуру классов, как описываешь интерфейсы и т.д.
В отображении не должно быть логики - да, обычно когда такое говорят, имеют ввиду именно бизнес логику :) Это такое сокращение, которое обычно воспринимается как очевидное.
Контроллер плохо называть клеем между (моделями) бизнес логикой и представлениями (отображением). У контроллера есть одна основная задача - обработать запрос. То есть ему надо принять решение о том, что хочет пользователь, выполнить нужные действия, и показать пользователю ответ. Иначе, если бы контроллер был клеем между моделями и представлениями, то по данному шаблону было бы запрещено отправлять модели с данными в представления, а нужно было бы их разбирать на массивы и отправлять только массивы.
В контроллере запрещена работа с БД через 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 модель для работы с моделями? Хм, а не сервис ли это получается?
Здравствуйте, я тоже пришел к такому выводу и всю бизнес логику выносил в файл (пакет если он разрастается) под названием utils. Потому что в представлениях совсем не то место, а модели сильно распухают и плохо тестируются потом. Это надо пройти на своем опыте(!). Интересно было бы взглянуть на структуру этого пакета у Вас
Название services мне нравится гораздо больше. Погуглил - это действительно очень распространенный подход а я дошел до него только после года фриланса и работы работы над приложениями за зарплалу. Как же многого мы (я) еще не знаем...
Неплохо, но упущено много важных моментов. Не всегда и не везде есть принципиальная возможность выносить всю логику за пределы view-метода. Как быть если нам нужно проверить атрибуты объекта ещё до момента инициализации сериализатора? Что если у нас имеется over-100500 полей и параметров, с которыми работает сервис? А если мы в одном запросе работаем с объектами разных типов, получится ли это сделать без затрагивания слоя представлений?
Отличная информация и ее подача, все доступно и наглядно. Большое спасибо!
Спасибо, рад, что полезно!
А пример джанго проекта с правильной бизнес-логикой можешь показать, а то в итоге какая-то дыра... там писать нельзя, тут тоже нельзя, зато можно вон там в уголочке, но вот как это делать не совсем понятно(совсем непонятно)
Так он же показал. Делаешь отдельный пакет и там строчишь бизнес-логику. Потом подтягиваешь её во views.
@@caesarfatalhammer я не говорил про бизнес. Я попросил показать практически правильное решение того, о чем он говорит. Потому что, как сказал автор, большинство пишет бизнес-логику в моделях или во вьюхах.
Подхода, о котором он говорит, я не встречал ни в одном уроке, поэтому соответствующая просьба.
Так что твой ядовитый высер здесь ни о чем...
@@WorldCount Ну он показал как это выглядит(как папочки лежать должны), а я прошу о тупом примере работы этих сервисов. Потому что мне непонятно зачем выводить в отдельный сервис, например, добавление товара в корзину, или оформление заказа, если мы говорим об интернет-магазине. Таким образом получится, что во вьюхе останется 2 строчки кода (вызов сервиса и return какие-то данные). Вот в этом вопрос. Зачем такое сильное дробление?
Предполагаю, что в больших проектах оно необходимо. Я в таких не участвовал. Поэтому хочу услышать ответ от опытного человека, который занимается тем, что делится знаниями посредством своего ютуб канала. Зачем отдельный пакет с сервисами и почему это эффективнее, чем писать методы к моделям и писать БЛ во вьюхах.
@@MrBytmin Спасибо за развернутый комментарий. Действительно в видео об этом говорилось, но почему-то не уложилось по полочкам. После вашего ответа стало немного понятнее.
Но все же посмотрев на код, было бы еще понятнее))
"правильной бизнес-логикой"
Для меня например загадка зачем тащить MVC в Джангу. Правильным скорее будет то, что по дефолту. А по дефолту в Джанге - MVT.
Класс! Наконец-то это ктото объяснил. Вы - спасение
То есть в services пилить логику, а во views оставить только return render?
Как раз в универе недавно проходили MVC, суть та же. Спасибо, что разобрали, так понятней стало
Отлично!
У вас в универе проходят мвс? А это где?
Недавно начал смотреть Django просто для расширения кругозора.
Было странно видеть разделение models, view, templates, кроме
того, почему в каждом из файлов содержится сразу несколько классов, это ведь неудобно?
Далее меня удивило то, что в моделях должна содержатся вся бизнес логика + логика работы с БД.
По крайней мере такое впечатление складывается когда смотришь
документацию и некоторые проекты на github.
Со слов автора видео понял что так делают не все, что радует.
По поводу бизнес логики, я бы вынес ее в отдельное место и назвал бы это Domain, Services как по мне это больше служебные классы.
Для запросов в БД есть паттерн Repository, для более сложных случаев можно использовать Specification.
Модели в данном случае оставить просто как маппинг на таблицы БД.
К слову, например в том же Symfony PHP фреймворке все организовано куда интересней.
Есть ли ссылка на более подробное описание в примерах реализации services в django?
Ссылки нет. Думаю, разберём на живом примере как-нибудь
ruclips.net/video/yG3ZdxBb1oo/видео.html
Спасибо за актуальное видео!))
Как раз делаю проект на джанге.
models.py - это модели Django, отображающие структуру БД
@@t0digital еще несколько раз пересмотрел, чтоб понять mvc что такое и как в джанго это реализовано))
Во многих фреймворках новички пишут бизнес-логику в моделях, т. к. им кажется, что больше негде. Опытные люди обычно выносят бизнес-логику в сервисы, а в моделях остаётся только структура данных.
Это вы про микросервисную архитектуру ?!
@@bobobo500 Нет. Под сервисами я подразумеваю вспомогательные классы.
Очень правильное видео, побольше бы таких.
Стараюсь выносить логику в utils, не расширяя модели и контроллеры, но есть один очень непонятный момент в этом. 1) Джанга, как и DRF, содержит в контроллерах методы в стиле get_queryset и т.д., которые обращаются к модели и БД. Разве это ок? Конечно, можно заставить эти методы работать через сервисы, но насколько это практично, переопределять метод получения кверисета через сервис, дополнительно писать этот сервис? (Вариант с товарами надуман, т.к. там явно будет много логики, но, думаю, посыл понятен). 2) Пагинация - тоже вроде как бизнес логика, но в контроллере смотрится весьма гармонично. Что с ней? 3) Сериалайзеры - что делать с ними? Они неплохо смотрятся как "входной шлюз" для данных, которые мы получили в реквесте. Тоже их в сервис? 4) И сколько потом будет таких сервисов? Не получится ли какая-то каша, если для каждого чиха будет сервис? 5) Менеджеры - стоит ли вообще писать кастомы? Иногда удобно, но для себя пока не решил.
В последнее время очень много задумываюсь над архитектурой и пробую выносить логику в сервисы, но озвученные выше вопросы не дают покоя.
Хоспади, как же круто вы рассказываете!!! Спасибо!!
Спасибо!
Классное видео, а где можно увидеть пример реализации слоя "services" в Django ? Или может будет такое видео?
В этом докладе вроде были примеры. Собственно, весь доклад про это
ruclips.net/video/yG3ZdxBb1oo/видео.html
@@nkhitrov спасибо большое)
Спасибо за видео, пишу не на Питоне, но проблемы ровно те же в коде встречаю)
Часто попадается код в CRUDах, где из контроллера вызывается Repository. По факту та же история что и с Model из View, правильно?
ОЧЕ круто, ну вот теперь то наконец-то дошло (надеюсь)).
Отлично
Спасибо, только учусь, инфа важная)
Случайно набрёл на Ваш канал. Понравились видео по Vim, так как сам являюсь его горячим поклонником после Emacs, и по tmux. Особенно как их объединить для разработки. По MVC тоже понравилось, хоть с этой темой был знаком и ранее. Про Rust ваша фраза повеселила. Сам являюсь поклонником Rust и Golang. В них как раз нет классов и классам объявлен бой. Хотелось бы послушать рассуждения на эту тему или что нибудь по языку Rust. Python недолюбливаю. Относительно минимализма и vim с Вами полностью согласен. Стараюсь IDE не использовать совсем и работать в консоли. Спасибо и удачи каналу.
Спасибо! Думаю, по Golang будут материалы на канале:) по Rust в ближайшее время, наверное, нет
Да, интересно посмотреть по Golang. К тому же в Vim есть плагины для работы с этим языком.
Впечатляет как вы управляетесь с Python. Не совсем понятно как вы его используете в проектах. Это или скрипты, которые обрабатывают данные, или WEB приложения на Python?
Пишем и скрипты любые на питоне, в тч по обработке данных, и веб приложения
Golang как раз рассматриваю как замену узких мест питона
Golang для сетевых приложений очень хорош. В Python мне не нравится, что невозможно защитить код программы при передаче заказчику, что не всегда удобно или приходится шаманить с обёртками. Golang язык компилируемый. Также в Python табы управляют логикой программы. Да, код без скобок и точек с запятыми выглядит чище, но ошибки в отступе строк приводят к ошибкам в исполнении интерпретатором. С другой стороны конечно в Python очень много библиотек.
видео классное, но, мне, как начинающему программисту, хочется своими словами описать то, что понял/ не понял из видео.
В видео вы говорите, что бизнес-логика - это работа с корзиной: вызвать из бд по определенному запросу, и пройтись циклом, это с одной стороны. С другой стороны, насколько я понял, вы говорите, что бизнес-логика - слой servises - это чисто запросы к БД с необходимой фильтрацией.
Относится ли к бизнес-логике: посчитать количество заказов в корзине, посчитать сумму заказа, применить какую-то скидку на каждую позицию? Или это уже относится к контроллерам (меня тоже напрягает название view).
Мне понравилось решение в фреймворке fastAPI, там например вынесли бизнес-логику в отдельный модуль, в доке у них CRUD так выделили. Конечно добавляется ещё один слой, но выглядит масштабируемо и упорядоченно.
В джанге, почему-то, в доке такого не показывают.
по поводу модуля доставки вашего есть пару вопросов. - я правильно понял что его нужно оплачивать помесячно? (забыл оплатить и магазин не может принимать заказы?) - как происходит добавление новых служб доставки? (это делает уже тот кто приобрел программу? К примеру недавно мне пришлось делать интеграцию со службой доставки Стриж, и по-моему ее нет в списке вашего модуля. Или же в ежемесячную плату входят и любые доработки?) - для небольших магазинов я использую CMS MODx и не вижу ее в списке поддерживаемых. Пошел почитать как происходит интеграция и вижу что она на js. Каждая CMSка как правило уже содержит свои инструменты для оформления заказов, расчета стоимости и так далее. Каким образом информация о заказе, оформленном через ваш модуль будет взаимодействовать с уже имеющимися в MODx сущностями заказа, статусами состояния заказа и так далее? (при учете что как такого api у modx для решения этих задач нет) ну и плюс тот же вопрос - доработка модуля под конкретную задачу уже входит в ежемесячную сумму? Спасибо.
_я правильно понял что его нужно оплачивать помесячно? (забыл оплатить и магазин не может принимать заказы?)_
Да, сервис платный, без денег не работает:)
_как происходит добавление новых служб доставки?_
Что-то сложное - через нас, а свою простую курьерку или пункт выдачи можете добавить сами в личном кабинете.
Modx модуля нет, интеграции под них соответственно тоже. Запросов на Modx большого количества тоже нет, так что не уверен, что будем делать в ближайшее время.
Интегрировать всё на js не получится, информацию о доставке надо ведь сохранять в CMS. Плюс выгрузка заказов и тд. Полноценная интеграция это непросто.
@@t0digital Спасибо, я видимо не совсем правильно понял суть. Считал, что это просто некий отдельный модуль, который будучи установлен на сайт работает обособленно и исключительно локально. Такие модули как правило имеют разовую фиксированную стоимость. А у Вас получается, что модуль это лишь некий клиент, работающий с вашим сервисом и данные хранятся на ваших серверах. Тогда понятно откуда стоимость в виде ежемесячной подписки. Удачи в его популяризации, выглядит эффектно и особенно порадовала приятная и понятная документация по api, что редко встретишь.
@@АлександрМельник-ч3ь спасибо! Да, мы храним все тарифы и данные у себя, обновляем их и позволяем гибко настраивать. Помимо гибкости настройки это даёт большой буст в скорости работы - API служб доставки медленные и ненадежные, отваливаются часто (привет СДЭК), мы это решаем как раз за счет хранения данных у себя
По поводу отсутствия в Django возможности обратиться к БД из шаблона: разве код {{ foo.bar_set.all }} в шаблоне не приведет к запросу?
Спасибо! Очень круто
классная кружка в японском стиле =)
Спасибо:) нравится тоже:)
Оставь ссылку на клавиатуру))
блин. Ну про Джангу прям молодец! Но есть вопрос. У Вас слой сервисов работает по принципу паттерна репозиторий? (для того, чтобы достать все заказы к примеру вы используете методы модели или так же делаете прослойку этих методов в сервисном слое?)
Респектую ребята!!! Отличное объяснение!
Спасибо!
Я так и не научился по человечески писать код на PHP,, но мой велосипед потихоньку приходит к модели MVC :)
Вы на верном пути и это главное!
Например, такое это бизнес логика? Такое тоже стоит выносить в отдельный слой?
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)
Получение данных с ORM - бизнес-логика. Работа с GET параметрами - не бизнес-логика. Контроллер получает данные из входных параметров HTTP запроса, возможно валидирует их (валидация может быть частью контроллера или частью бизнес-логики) и затем вызывает слой бизнес-логики, отправляя в него полученные на вход и возможно провалидированные параметры. Получает ответ от БЛ и использует его для формирования HTTP ответа.
@@t0digital Спасибо. Не часто отвечают на вопросы в видео годовалой давности. В общем надо мне довольно много кода править :)
Cпасибо за объяснения MVC. Изучал Django по книжке Дронова и очень сильно раньше бесился, почему автор упорно называет вьюхи контроллерами. Теперь понимаю, откуда растут ноги. Интересно было бы узнать, чем руководствовались создатели Джанги, когда вводили такую архитектуру и нейминг.
Да, мне тоже интересно, почему так
@@t0digital может потому что Django реализует не MVC а MVT архитектуру?)
@@Орест-к9к не суть вообще
3:20 Сортировку массива перед показом можно в отображение запихнуть? (при условии что в бизнес модели этот массив отсортированный не используется)
Я думаю, что да, это может быть логикой отображения. Не все шаблонизаторы это поддерживают, поэтому можно перенести это в контроллер. Частые задачи контроллера это форматирование, сортировка данных, пришедших от модели, и затем уже передача их в отображение
@@t0digital Спасибо!
И тут все круто! Спасибо, кодер, от Котана ))))
Спасибо 🙏
Я правильно понял. Что добавление товара в корзину лучше не делать во View приложения. А поручить это например api rest?
API REST не имеет никакого отношения к теме вопроса. Во View добавления товара в корзину быть не должно, View должен вызывать функции добавления в корзину, определенные не во View.
А где писать запросы в БД если не во view?
Спасибо за видео! Очень доходчиво.
Сделай пожалуйста видос про выбор лицензии проекта при создании репозитори на гитхабе. в чём между ними различия и какую для какого проекта лучше выбрать.
Погодите. Я уточню для себя, если позволите. Модели в Джанго, да и не только в нем (например в Ларавеле тоже), по сути отвечают за коммуникацию с базой. То есть, что-то внести/извлечь в/из базы? Одновременно с этим, у разработчиков парадигмы MVC, есть пожелание, которое, по хорошему, является правилом - контроллеры должны быть худыми... И вот тут вопрос, как же писать бизнес логику? И как ее писать в модели? Если в Джанго модели содержат в себе, по сути, просто поля которые содержит база. Тут я допускаю, что я просто не образован а этом плане (по этому и спрашиваю), например как я делал в Ларавеле - создавал отдельные классы в отдельных файлах и к ним обращался из контроллеров, а в этих классах уже взаимодействовал с базой (честно, делал это посредством сырых запросов в БД, то есть, даже без моделей) и возвращал контроллеру данные для передачи во вьюху... Так как же правильно делать в джанге?
Про Лару не скажу, с ней не работал, но в Django как такового слоя для бизнес-логики не предусмотрено в стандартных слоях. Кто-то рекомендует писать бизнес-логику в моделях, но я не считаю это правильным. Модели - описание структуры данных для БД/ORM, это не лучшее место для бизнес-логики. Я рекомендую создавать модуль services.py и писать БЛ туда, или, если БЛ много, то создавать пакет services, и делать в нём несколько модулей (файлов) с бизнес логикой.
@@t0digital спасибо большое. По сути, как я понял это такой же подход как у меня в ларке был. То есть создаём отдельный файл с классами (если необходимо из несколько) и там уже занимаемся "развратом" с данными)) возвращаяя в views обработанные данные.
Спасибо Вам большое. Вот, не примите как подхалимство, но Вы наверное один из не многих, если не единственный, настоящий практик в ютьюбе(это чувствуется), который действительно рассказывает как надо. За это Вам огромное спасибо от таких джунов как я))
Если позволите, вот просьба как, именно, от джуна, который не имеет коммерческого опыта (хотя писал несколько приложений и web в том числе), не могли бы вы на примере какого нибудь проекта показать как это происходит в коммерческой разработке. От момента, вот приходит человек на проект, ему дают репозиторий, он его клонирует, выполняет задачу свою, коммитит на ревью, потом, сливается в общий репозиторий... Этого маслята, типа меня, как раз не знают и не понимают до конца. И это пугает )))
Відео годнота!
Спасибо
Можете снять ролик где более подробно расскажите о создание правильной архитектуры с джанго на каких то близких к реалиям примерах?
Спасибо! Такое видео будет
Согласен.Помню писал сайт обьявлений - тупо делил на апсы без использования бизнес логики(Использовал только отдельные тулы).Недавно договорился заказчиком на саппорт сайта.Ну вот - поплыл в своем коде
А что насчет DRF? В документации DRF очень много примеров того, как во views происходят прямые обращения к БД.
Что-то типа:
class UsersList(ListAPIView):
queryset = User.objects.all()
serializer_class = UsersListSerializer
Это же нарушение MVC, нет?
Drf часто провоцирует на плохой код, да
Приветствую!
1. Огромное спасибо за контент! Всегда приятно смотреть и слушать!
2. Можно ли получить пример по данному видео?! Хотелось бы наглядно посмотреть на организацию и логику распределения функций/классов/etc...
Это код одного из наших проектов, не могу его показать. Но сделаем какой-то живой пример может быть на стриме, на нем все будет понятно
Диджитализируй! АйТи студия я понял сразу какой это проект :) Поэтому и попросил что-то на коленке - петпроджект какой-то изобрести с той структурой, которую описываете.
Собственно говоря меня именно этот момент все время тормозит в Джанго 😩
@@jtprogru_channel да, сделаем!
А что у вас за монитор на стене?
Моник LG какой-то. Он на подъёмном столе стоит
Расскажите про контроль версий для проектов (для файллв и для бд)?
про Git будет материал. Версионность БД в минимальном виде это механизм миграций в Django, аналогичный есть в других фреймворках
Спасибо! Ещё раз упорядоченно об этом услышал
Использовать сервисы внутри джанго аппликаций - хорошая идея. Но как тогда быть например с generic views или model serializers/forms? GenericView не может существовать без relation на django model. В ModelSerializer и ModelForm тоже самое. Более того - там есть методы create, update, save -уже точно не помню как они називаются, но не суть. Если бизнес логику вынести отдельно - то вышеперечисленные инструменты не очень подойдут. Этo сильные инструменти django и если ними не пользоватся тогда зачем django нужно, если есть например Flask?
Django не лучше и не хуже Flask, они просто разные. Во Flask вы накручиваете любые нужные инструменты сами, Django даёт вам готовый неплохо собранный каркас с ORM, миграциями, надстройками для тестов, формами, отличной админкой и тд.
Что касается бизнес-логики и джанговых/DRF методов create/read/update - они могут быть и вызывать слой бизнес-логики (сервисов)
Секундочку ...
Т.е. в services описана общая логика запросов в БД, которая подходит и к вебу и к DRF?
Звучит конечно интересно, но не является ли это множителем кода? Вьюшки работают с реквестами, сессиями и делают (в лучшем случае) по 1 запросу в БД.
АПИ, там формы и страницы отличаются от веба, и андроиды-разработчики могут слать тебе скопом всю инфу, когда им удобно.
Хотя, конечно, это придирки.) Дайте, плиз, какую ссылочку на гитхабе, где services, объединяют бизнез логику АПИ и веба.
Принципиальной разница API и веба нет. Схема работы API - пришел запрос в контроллер (джанговый views), контроллер распарсил его, возможно проверил корректность данных в запросе, запросил данные в сервисах, получил их и вернул в JSON клиенту. Схема работы веба такая же, просто на последнем шаге данные вернутся не в JSON клиенту, а в template, который их вставит в HTML и клиенту улетит HTML с данными.
Спасибо, очень полезно!
Доступным языком, не плохо)
Спасибо
Что такое контроллер?
А разве запросы к бд не должны быть в ДАО, к которому обращается слой бизнес логики?
Огромное спасибо. Я уже успел задуматься, почему view, когда там обрабатываются запросы. Твоё решение кажется супер крутым, спасибо. Конкретно в моем случае, очень поможет. Не мог бы ты или другие люди в коментах ответить на мои вопросы?
Я реализую приложение для документооборота.
1) Имеется несколько должностей работников, для каждой описал отдельный модуль.
Поскольку у работника может быть несколько ставок, сделал такую связь: User -> Worker -> WorkerPosition
Не смог понять структуру классов/таблиц и что за данные в них по описанию - надо вникать более глубоко, чтобы ответить на вопросы
Здравствуйте. Вопрос мучает меня. Пишу MVC приложение на C#. Нужно получать записи с учётом пагинации, фильтров, сортировки и всё это в разных комбинациях. Не хочется плодить кучу методов для разных вариантов выборки данных в сервисе, да и выглядит это, как задачи контроллера.
Как правильно решать такие ситуации? Давать доступ контроллеру к орм для выборки, или добавлять методы в сервис?
Привет! Не надо ходить в ORM из контроллера, эту логику надо выносить в отдельный слой 100%. Как именно на уровне бизнес логики её лучше сделать вопрос второй, но все фильтрации и подобное должны быть там. Сортировка данных на мой взгляд допустима в контроллере, но фильтры в отдельном слое.
@@t0digital Спасибо. Было устойчивое желание опустить слой бизнес логики, а тут ваше видео.
Forms & Signals, не? Хотя, можно и отдельный сервисный слой.
Сигналы это вообще ОЧЕНЬ спорное решение в джанго, дебажить это потом боль. У форм область применимости небольшая.
Сколько не читал/смотрел/изучал примеры 99% пихают логику в Views, что-то мелкое в методы класса модели, называя это вычисляемыми полями (если вывод информации), или в метод save если требуется что-то сделать с инстансом, но никто не выносит в отдельные "файлы". При этом в работе столкнулся с тем, что если "засунуть" все во View то начинается боль в определенном месте, и в итоге пришел к такому выводу:
- сложная логика, т.е. логика затрагивающая N моделей и/или требующая расчета/анализа, т.е. действий над данными - отдельные модули с классами для работы с нужными моделями (проверки, логика, сохранение, обновление)
Т.е. по сути тут даже логически придешь к выводу, что нужно вынести это куда-то иначе твоя вьюха или модель станет просто не читаемым куском г..на
Пихать же все в модель верх безумства, на примере своей работы уже задумываюсь даже вычисляемые поля выносить с моделей, ибо 20 полей модели + 20 вычисляемых, которые частично могут затрагивать другие модели это печаль и простыня, а если туда еще запихнуть логику - тушите свет.
Спасибо, что поделились! Всё именно так и есть
Вот есть вопрос. Про модели в Джанго согласен полностью, как и вообще со всем видео, но... В одной книге, проверка пароля, определяется в классе модели, а вызов этого метода происходит в views.py, т.е. в модели. Выглядит вроде прилично. По опыту, можно так отступать, или лучше вывести это в отдельный класс? И про миксины хотелось бы узнать мнение. Если к примеру вывести часть бизнес-логики в миксин, не нарушит ли это MVC?
с миксинами надо быть аккуратненько, это множественное наследование, можно выстрелить себе в ногу случайно. Миксины должны быть очень маленькими и минималистичными, а бизнес-логика такой бывает редко
Какой у вас дополнительный монитор?
Классный канал!
Спасибо! Это монитор LG 27" с type c 4к модель, не помню номер
Спасибо за видео. Хотелось бы узнать, планируется ли раскрытие таких тем как Domain Driven Design, Test-Driven Development и т.п. ? Заранее спасибо за ответ.)
Да, обязательно будет
@@t0digital Отлично)
Не раз возвращаюсь к этому ролику) у тебя очень позитивные и полезные видео, так держать! :)
Может подскажешь, что лучше использовать для вида приложения в веб: чистый css (scss) или bootstrap?)
P.S. Сейчас перехожу с flask на django
Если по-быстрому и особо не вникать, то фреймворки, а так лучше css изучить чистый, он сейчас модный и достаточно простой в использовании
Всегда нравились аргументы типа - "Это бред, это бред"
Очевидно мне тоже
За такой видос, ссылку в ВК опубликовал. Спасибо
Спасибо!
Очень крутое видео! Объяснил много моментов, на которые негде было найти ответы. Но один вопрос ещё остался: Model.objects.all() и подобные вызовы тоже выносить в сервисы? Если да, то как это делать правильно? Было бы очень круто, если бы ты сделал видео с наглядным примером как именно что либо выносится в отдельный слой!
Я вообще все во вьюхах делал🤦🏻♂️ а оказывается, что это говнокод😁
@@maksimangerman6238 жиза)