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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо

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

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

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

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

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

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

спасибо

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

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

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

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

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

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

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

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

8:00 жиза.. всё круто

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

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

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

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

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

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

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

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

А знают ли программисты, какой процесс в бизнес-логике нужно или лучше считать главным, чтобы преуспеть самому программисту?

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

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