Комментарии 20
А что за курс?
Джанго это не просто конструктор сайтов, это набор инструментов (стамеска, рубанок, пила ...), с помощью которых нужно построить свои "детали конструктора" (ящик, шкафчик, кроватка ...) и только потом расставлять свои изделия по квартире (проекты по страницам сайта). Уровень вхождения несколько выше, если брать с нуля. Вот DjangoCMS - это конструктор. Это с моей точки зрения.
Джанга -- это такой маленький PHP в мире питона. А вообще есть много инструментов сильно лучше
Джанга вышла в 2005, а Laravel в 2011, так что очевидно кто кого косплеил.
Хотя может быть что оба косплеили Ruby on Rails из 2004.
Я про Laravel ничего не говорил. Вы пробовали читать то, что написано, а не то, что вы сами себе придумали?
Я сварщик не настоящий, но есть пара наблюдений на тему django.
Смущает предложение складывать все модели приложения в один файл. Тоже про views. При даже небольшой сложности, порядка десятков моделей / экшенов это будут огромные простыни, в которых трудно ориентироваться, риск конфликтов при параллёльной разработке и т.п. в общем прелести нарушения SRP.
Model-View разделение из коробки есть, но, не видно связывающего их слоя ни во фреймворке, ни в примере. Это создаёт соблазн нахлабучить бизнес-логику в предлагаемых компонентах, что хуже опухших контроллеров, чем грешат джуны в пресловутых MVC-фрейворках.
Функция представления обрабатывает запрос и выполняет все необходимые
действия, такие как получение данных из базы данных или выполнение
бизнес-логики.
Модульное тестирование при таком подходе обещает отдельную боль.
Примеры в хелловорлдах не являются правилом, в документации таких требований нет. Можно даже view.py переименовать в controller.py (я так делал в одном проекте) и оно всё равно будет работать. В конце концов это просто питон и никто не запрещает разбить контроллер на подмодули.
Можно вместо views.py создать папку views, в ней файлик __init__.py
, и импортировать отдельно каждую вьюшку из своего файла. Во всех остальных файлах ничего не поменяется - `from views import MyView` так и останется.
Я так делаю с моделями - бывают проекты где больше сотни моделей надо использовать.
Спасибо за такой развернутый и утыканный терминами комментарий. Смысл данной статьи(и последующих) в понятном объяснении. Чтобы человеку, который только начал изучение, не приходилось рыть информацию по каждому умному слову в интернете. И на данном этапе "SRP", "MVC" и другие модульный тестирования абсолютно лишние. Если есть желание поучаствовать в написании таких понятных обывателю статей, то прошу присоединяться.
Многие люди и бросают заниматься чем-то хорошим, потому что на большинстве форумов опытные старожилы шлют их "курить мануал". И чаще всего мануал бывает очень непонятным.
В современном вебе от Джанго, пожалуй, нужно только DRF, Django ORM, Permissions + иногда может быть полезна админка как минимальный бекофис. Остальное уже не особо актуально ;)
Джунам учить как там с templates работать в джанге - скорее, в рамках курса истории может понадобиться, разве что. (ну или ты стартапер который еще возьмет htmx и будет делать mvp со световой скоростью)
И тем не менее, я сейчас это прохожу на курсе...
Очень надеюсь вы не у "мудрёного 'совуна' ". А то замечание da_malcev'a до вас не доведут.
На что сейчас предлагаете ориентироваться в современном вебе вместо Джанго. Без иронии, просто любопытно
В целом, для своих задач Джанго хороший вариант.
Но если выбирать что-то более современное для веба на python, то тут, конечно, сейчас в лидерах FastAPI - дает возможность писать сходу API без необходимости еще что-то сверху устанавливать, сам генерирует базовую API документацию, сразу поддерживает асинхронность. Берете к нему еще какую-нибудь ORM (SQLALchemy - самая популярная, пожалуй), чтобы с БД работать - и вот у вас уже быстрый и довольно легкий бекенд есть.
Для новичков, сейчас, наверное даже кофмортнее знакомится с бекендом начиная с FastAPI, все таки там куда меньше концепций из коробки идёт и можно как раз постепенно повышать сложность добавляя библиотеки с нужным функционалом, а не нырять с головой в огромный Джанго, где часть вещей уже и не актуальны.
P.S. Вместо FastAPI можно начинать с Flask, там на базовом уровне все так же, просто материалов в сети по нему больше. Но FastAPI сейчас гораздо более востребован чем Flask.
Хотя если посмотреть на вакансии - в половине требуют Джангу
Подскажите, сколько процентов статьи представляют именно ваши наблюдения и выводы, а сколько ответы, сгенерированные нейросетью (ИИ)?
Я не понимаю, что именно вам не удалось найти в русскоязычном интернете в 2022-2023 годах. Однако, то, что вы описали, доступно как в документации, так и в сопутствующих гиперссылках. Кроме того, такая информация, вероятно, содержится во многих книгах по Django, включая "Джанго в примерах" Антонио Меле. В этой книге, помимо таких концепций, как MVT, файловая структура проекта (контейнер проекта или верхняя папка проекта) и приложения внутри этого контейнера, также подробно описаны миграции, кастомизация административного интерфейса, циклы запрос-ответ, разбор файла settings.py и многое другое.
Все это рассматривается в первой главе на примерно 50 страницах. Я сам только что окончил курсы по Python и Django, и пока ваша статья даже не позволяет мне иметь поверхностное представление о том, что такое Django.
Я бы предложил вам упомянуть, хотя бы для полноты картины, что такое фреймворк в целом, без лишних вод, чтобы дать читателям более полное представление и уже переходить к рассмотрению самого фреймворка.
Что же такое Django?