17 месяцев назад я начал свою путь в бэкенд разработку Python. Но спустя время я начал сталкиваться со сложностями в обучении на своей платформе. Первые уроки давались легко, а потом начиналось что-то непонятное в буквальном смысле. Заучивание, записывание, практика одного урока - на это уходили дни. А уроков сотни.
Чтобы найти простое объяснение и понять 10 минутный урок, приходилось несколько часов серфить интернет и потеть над кодом, выявляя правильный путь исправления ошибок. Везде говорят, что в первую очередь нужно учиться искать информацию в интернет. Но сейчас, когда я изучаю Django, даже "перекурив" весь русскоязычный мануал, я не понял ничего. В каждом предложении нужно "гуглить" термины. В сотрудничестве с ИИ я попробовал дать простое объяснение, которое поймет даже первоклассник.
Я только учусь и курс Django пройден наполовину. Все это сделано для тех, у кого тоже возникли трудности.
Что такое джанго
Джанго - это специальный инструмент, который помогает разработчикам создавать веб-сайты и приложения. Он называется фреймворком, потому что предоставляет готовые инструменты и правила для работы с веб-сайтами.
Джанго нужен для того, чтобы упростить процесс разработки веб-сайта. Вместо того, чтобы создавать каждую часть сайта с нуля, разработчики могут использовать Джанго, чтобы получить уже готовые компоненты и функциональность.
Джанго имеет много полезных функций, которые помогают создавать веб-сайты:
Он позволяет создавать красивые и интерактивные страницы, которые пользователи могут видеть в своих браузерах.
Он облегчает работу с базой данных, где хранится информация о веб-сайте, такая как список товаров или информация о пользователях.
Он помогает обрабатывать запросы от пользователей и отправлять им нужную информацию.
Он имеет мощный административный интерфейс, который позволяет администраторам управлять содержимым веб-сайта без необходимости знать программирование.
Таким образом, Джанго помогает разработчикам создавать веб-сайты более быстро и эффективно, предоставляя им готовые инструменты и структуру работы. Он широко используется для создания различных веб-сайтов, таких как блоги, интернет-магазины и социальные сети.
Что такое проект джанго
Давай представим, что проект Django - это интернет-магазин, а приложения внутри этого проекта - это его различные части или функциональности.
Когда мы говорим о проекте Django, давай вообразим, что это сам интернет-магазин в целом. В нем мы можем купить товары и просмотреть информацию о них.
-
Теперь представьте, что у нас есть несколько разных приложений, которые делают разные вещи внутри этого интернет-магазина.
Одно из таких приложений может быть "Каталог товаров". Здесь мы можем просмотреть список всех товаров, их названия, изображения и цены. Это как книжка с полным списком товаров в магазине.
Еще одно приложение может быть "Корзина покупок". Здесь мы можем добавлять товары в нашу корзину, изменять количество товаров и видеть общую стоимость наших покупок. Это как корзина, в которой мы кладем товары, пока не решим купить их окончательно.
И еще одно приложение может быть "Оформление заказа". Здесь мы можем указать наш адрес доставки и подтвердить наш заказ. Это как заполнение специальной формы, чтобы магазин знал, куда доставить наши покупки.
-
Внутри каждого приложения у нас есть файлы, которые делают разные вещи:
У "Каталога товаров" есть файлы, которые описывают модели товаров (как они выглядят и что имеют), представления (как мы показываем список товаров пользователю) и шаблоны HTML (как страница с товарами выглядит).
У "Корзины покупок" также есть файлы, которые описывают модели корзины и элементов корзины, представления для добавления/удаления товаров из корзины и шаблоны HTML для отображения корзины.
У "Оформления заказа" есть файлы, которые описывают модели заказов и информации о доставке, представления для оформления заказа и шаблоны HTML для отображения формы оформления заказа.
Все эти файлы работают вместе, чтобы создать полноценный интернет-магазин. Они сообщаются друг с другом и используют функции Django, чтобы обрабатывать запросы пользователей и отображать нужные страницы.
Таким образом, проект Django - это целый интернет-магазин, а приложения - это его разные части, которые делают определенные задачи. Каждое приложение имеет свои файлы, которые описывают модели, представления и шаблоны, необходимые для работы этой части магазина.
От запроса до отрисовки страницы
Вот основные этапы и внутренние действия, которые происходят при обработке запроса и отрисовке страницы в Django:
Пользователь открывает браузер и вводит адрес веб-сайта (URL) в строке поиска.
Браузер отправляет запрос на сервер, где расположен веб-сайт.
Сервер получает этот запрос и передает его в Django.
Django получает запрос и смотрит на URL, чтобы понять, какая страница должна быть показана.
Django проверяет файл
urls.py
в своей структуре проекта, чтобы найти соответствующий URL-шаблон для этой страницы.Когда Django находит соответствующий URL-шаблон, он вызывает соответствующую функцию представления (view function).
Функция представления обрабатывает запрос и выполняет все необходимые действия, такие как получение данных из базы данных или выполнение бизнес-логики.
Если данные нужны для отображения страницы, Django может использовать модели данных и базу данных для извлечения этих данных.
Далее Django использует шаблон HTML, который соответствует этой странице, чтобы создать окончательную HTML-страницу.
Django заполняет шаблон данными, которые были получены из базы данных или обработаны функцией представления.
Окончательная HTML-страница готова и возвращается обратно на сервер.
Сервер отправляет эту HTML-страницу обратно в браузер пользователя.
Браузер получает HTML-страницу и начинает ее отображать, показывая пользователю содержимое страницы, такое как текст, изображения и ссылки.
Вот таким образом происходит процесс от запроса до отрисовки страницы в Django!
Структура стандартного простого проекта
Вот пример структуры файлов интернет-магазина в Django:
myshop/
├── manage.py
├── myshop/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── catalog/
│ ├── migrations/
│ ├── __init__.py
│ ├── admin.py
│ ├── models.py
│ ├── views.py
│ └── templates/
│ └── catalog/
│ ├── product_list.html
│ └── product_detail.html
├── cart/
│ ├── __init__.py
│ ├── models.py
│ ├── views.py
│ └── templates/
│ └── cart/
│ └── cart.html
└── checkout/
├── __init__.py
├── models.py
├── views.py
└── templates/
└── checkout/
└── order_confirmation.html
Теперь давай объясню, за что отвечает каждый файл:
manage.py
: Это скрипт для управления Django проектом. Он позволяет выполнять различные команды, такие как запуск сервера или выполнение миграций базы данных.-
myshop/
(каталог): Это основной каталог проекта Django.__init__.py
: Пустой файл, который указывает на то, что эта директория является пакетом Python.settings.py
: Файл настроек проекта, содержащий информацию о базе данных, статических файлах, шаблонах и других параметрах.urls.py
: Файл URL‑маршрутов проекта, определяющий, какие представления (views) будут обрабатывать запросы для каждого URL‑адреса.wsgi.py
: Файл для настройки WSGI‑совместимого сервера (Web Server Gateway Interface), который позволяет запускать Django приложение на веб‑сервере.
-
catalog/
: Приложение «Каталог товаров».migrations/
: Директория, содержащая миграции базы данных, которые определяют структуру таблиц и схемы данных.__init__.py
: Пустой файл, указывающий на то, что эта директория является пакетом Python.admin.py
: Файл, определяющий административный интерфейс для управления товарами.models.py
: Файл, содержащий модели данных, такие как классы для товаров или категорий.views.py
: Файл, содержащий представления (views) для отображения страниц с товарами.templates/
: Директория, содержащая HTML‑шаблоны для визуального оформления страниц.
-
cart/
: Приложение «Корзина покупок».__init__.py
: Пустой файл, указывающий на то, что эта директория является пакетом Python.models.py
: Файл, содержащий модели данных, такие как классы для корзины покупок или элементов корзины.views.py
: Файл, содержащий представления (views) для добавления товаров в корзину, изменения количества и оформления заказа.templates/
: Директория, содержащая HTML‑шаблоны для визуального оформления страниц корзины.
-
checkout/
: Приложение «Оформление заказа» (продолжение).models.py
: Файл, содержащий модели данных, такие как классы для заказов или информации о доставке.views.py
: Файл, содержащий представления (views) для оформления заказа и подтверждения заказа.templates/
: Директория, содержащая HTML‑шаблоны для визуального оформления страниц оформления заказа.
Это лишь пример структуры интернет-магазина в Django, и в реальном проекте может быть больше файлов и каталогов, в зависимости от функциональности сайта.
Комментарии (19)
Stas_VTK
11.07.2023 08:33+2Джанго это не просто конструктор сайтов, это набор инструментов (стамеска, рубанок, пила ...), с помощью которых нужно построить свои "детали конструктора" (ящик, шкафчик, кроватка ...) и только потом расставлять свои изделия по квартире (проекты по страницам сайта). Уровень вхождения несколько выше, если брать с нуля. Вот DjangoCMS - это конструктор. Это с моей точки зрения.
kai3341
11.07.2023 08:33-5Джанга -- это такой маленький PHP в мире питона. А вообще есть много инструментов сильно лучше
AcckiyGerman
11.07.2023 08:33+1Джанга вышла в 2005, а Laravel в 2011, так что очевидно кто кого косплеил.
AcckiyGerman
11.07.2023 08:33+3Хотя может быть что оба косплеили Ruby on Rails из 2004.
kai3341
11.07.2023 08:33А вот это правда. Я помню, какую революцию поднял RoR -- я всерьёз тогда думал учить Ruby
kai3341
11.07.2023 08:33Я про Laravel ничего не говорил. Вы пробовали читать то, что написано, а не то, что вы сами себе придумали?
AcckiyGerman
11.07.2023 08:33Вы сами себе придумали, что "Джанга это маленький PHP в мире питона", а мне запрещаете ассоциировать Джангу с Ларавелем?
Сначала покажите удостоверение полиции мысли.
samizdam
11.07.2023 08:33+2Я сварщик не настоящий, но есть пара наблюдений на тему django.
Смущает предложение складывать все модели приложения в один файл. Тоже про views. При даже небольшой сложности, порядка десятков моделей / экшенов это будут огромные простыни, в которых трудно ориентироваться, риск конфликтов при параллёльной разработке и т.п. в общем прелести нарушения SRP.
Model-View разделение из коробки есть, но, не видно связывающего их слоя ни во фреймворке, ни в примере. Это создаёт соблазн нахлабучить бизнес-логику в предлагаемых компонентах, что хуже опухших контроллеров, чем грешат джуны в пресловутых MVC-фрейворках.
Функция представления обрабатывает запрос и выполняет все необходимые
действия, такие как получение данных из базы данных или выполнение
бизнес-логики.Модульное тестирование при таком подходе обещает отдельную боль.
Nasreddin_Hodja
11.07.2023 08:33Примеры в хелловорлдах не являются правилом, в документации таких требований нет. Можно даже view.py переименовать в controller.py (я так делал в одном проекте) и оно всё равно будет работать. В конце концов это просто питон и никто не запрещает разбить контроллер на подмодули.
baldr
11.07.2023 08:33Можно вместо views.py создать папку views, в ней файлик
__init__.py
, и импортировать отдельно каждую вьюшку из своего файла. Во всех остальных файлах ничего не поменяется - `from views import MyView` так и останется.Я так делаю с моделями - бывают проекты где больше сотни моделей надо использовать.
AlanDreks Автор
11.07.2023 08:33Спасибо за такой развернутый и утыканный терминами комментарий. Смысл данной статьи(и последующих) в понятном объяснении. Чтобы человеку, который только начал изучение, не приходилось рыть информацию по каждому умному слову в интернете. И на данном этапе "SRP", "MVC" и другие модульный тестирования абсолютно лишние. Если есть желание поучаствовать в написании таких понятных обывателю статей, то прошу присоединяться.
Многие люди и бросают заниматься чем-то хорошим, потому что на большинстве форумов опытные старожилы шлют их "курить мануал". И чаще всего мануал бывает очень непонятным.
da_malcev
11.07.2023 08:33В современном вебе от Джанго, пожалуй, нужно только DRF, Django ORM, Permissions + иногда может быть полезна админка как минимальный бекофис. Остальное уже не особо актуально ;)
Джунам учить как там с templates работать в джанге - скорее, в рамках курса истории может понадобиться, разве что. (ну или ты стартапер который еще возьмет htmx и будет делать mvp со световой скоростью)
AlanDreks Автор
11.07.2023 08:33И тем не менее, я сейчас это прохожу на курсе...
AsphaltHero_0
11.07.2023 08:33Очень надеюсь вы не у "мудрёного 'совуна' ". А то замечание da_malcev'a до вас не доведут.
Adgh
11.07.2023 08:33На что сейчас предлагаете ориентироваться в современном вебе вместо Джанго. Без иронии, просто любопытно
da_malcev
11.07.2023 08:33+1В целом, для своих задач Джанго хороший вариант.
Но если выбирать что-то более современное для веба на python, то тут, конечно, сейчас в лидерах FastAPI - дает возможность писать сходу API без необходимости еще что-то сверху устанавливать, сам генерирует базовую API документацию, сразу поддерживает асинхронность. Берете к нему еще какую-нибудь ORM (SQLALchemy - самая популярная, пожалуй), чтобы с БД работать - и вот у вас уже быстрый и довольно легкий бекенд есть.
Для новичков, сейчас, наверное даже кофмортнее знакомится с бекендом начиная с FastAPI, все таки там куда меньше концепций из коробки идёт и можно как раз постепенно повышать сложность добавляя библиотеки с нужным функционалом, а не нырять с головой в огромный Джанго, где часть вещей уже и не актуальны.
P.S. Вместо FastAPI можно начинать с Flask, там на базовом уровне все так же, просто материалов в сети по нему больше. Но FastAPI сейчас гораздо более востребован чем Flask.
AsphaltHero_0
11.07.2023 08:33+1Подскажите, сколько процентов статьи представляют именно ваши наблюдения и выводы, а сколько ответы, сгенерированные нейросетью (ИИ)?
Я не понимаю, что именно вам не удалось найти в русскоязычном интернете в 2022-2023 годах. Однако, то, что вы описали, доступно как в документации, так и в сопутствующих гиперссылках. Кроме того, такая информация, вероятно, содержится во многих книгах по Django, включая "Джанго в примерах" Антонио Меле. В этой книге, помимо таких концепций, как MVT, файловая структура проекта (контейнер проекта или верхняя папка проекта) и приложения внутри этого контейнера, также подробно описаны миграции, кастомизация административного интерфейса, циклы запрос-ответ, разбор файла settings.py и многое другое.
Все это рассматривается в первой главе на примерно 50 страницах. Я сам только что окончил курсы по Python и Django, и пока ваша статья даже не позволяет мне иметь поверхностное представление о том, что такое Django.
Я бы предложил вам упомянуть, хотя бы для полноты картины, что такое фреймворк в целом, без лишних вод, чтобы дать читателям более полное представление и уже переходить к рассмотрению самого фреймворка.
nirom
А что за курс?
AlanDreks Автор
Бекенд Пайтон разработчик одной из крупных и рекламируемых онлайн школ. Название упоминать не буду.