что нужно знать для django
Что бы я хотел знать когда начинал изучать Django? — очень общий взгляд
Здесь на Хабре много различных инструкций по использованию Django. Эти инструкции часто включают много кода и представляют последовательность шагов, которые нужно сделать, чтобы создать проект.
Когда я начинал изучать Django и Wagtail по таким инструкциям, меня часто смущало, что пара команд создает кучу непонятных файлов (особенно на самом старте). Последующее описание этих файлов в инструкциях содержало слишком много деталей, которые трудно было усвоить за раз.
В этом посте я бы хотел посмотреть на Django с очень «философского вида» — минимум кода, максимум общих фактов. Думаю, что такой взгляд поможет тем, кто хочет начать изучать Django но теряется на старте.
Хочу также сказать, что не являюсь профессионалом по части веб-программирования — я в этой области скорее любитель, которого интересуют исключительно личные проекты — один из них сайт по расшифровке данных ДНК тестов https://ru.bezoder.com — написан на Wagtail.
Сначала давайте вспомним, что сайт в интернете это просто программа, которая, возможно, работает почти на таком же компьютере, что находится перед вами.
Ваш компьютер (телефон и т.п.) посылает какой-то запрос к чужому компьютеру в интернет, тот его обрабатывает и отвечает. При обработке чужой компьютер, возможно, делает запрос или производит запись в базу данных. Теперь представим, что необходимо запрограммировать компьютер в интернете, чтобы он правильно обрабатывал каждый запрос.
Это можно сделать вообще на каком угодно языке программирования — вы получаете запрос и на его основе что-то выполняете. Но представьте сколько может быть вариантов как запрограммировать этот компьютер — их может быть бесконечно много! Например, можно написать функцию что-то вроде:
Думаю, понятно, что это был бы ужасный вариант программирования.
Нам нужно сделать все так, чтобы код был читаемым, безопасным, легко дополняемым, использовал какие-то возможности языка, на котором написан…
С таким набором задач нужно придумать какую-то концепцию.
Концепция Django
Django предлагает все разделить на «слои«. Слои отвечают за разные составляющие вашей программы. Между слоями есть связь, но она не затрудняет разработку каждого слоя изолированно (без большого внимания к другим слоям) — в Django это называется loose coupling.
Вот несколько важных слоев Django:
Тут я немного подробнее остановлюсь на слоях Модели, Виды и Шаблоны.
Слой модели
Как видите, в базе каждая строка это запись, относящаяся к пользователю сайта. В строке есть данные различного типа — в нашем случае числа и текст.
Распространенным языком баз данных является SQL — определенными командами вы можете создавать новые таблицы в базе или вносить и получать данные в и из существующих таблиц.
У SQL есть уязвимости — подробнее. Вкратце — если определенным образом расставить кавычки и точки с запятой в данных, которые отправляются в SQL команду, часть этих данных может быть интерпретирована как составляющая SQL команды.
Django берет всю головную боль, связанную с проблемами SQL на себя — вам даже не надо знать SQL, чтобы пользоваться Django, от вас нужен только python — Django сам сформирует SQL команды для создания таблиц, поиска и записи данных в таблицы и все это будет безопасно.
Идея Django в том, что классы на python повторяют структуру таблиц вашей базы данных.
То есть, для таблицы выше я могу создать класс в python что-то вроде:
но как связать такой класс с базой данных? Вот тут начинается магия Django:
Вы просто используете django.db.models.Model чтобы создать класс, далее каждое поле в вашем классе это также поле, взятое из django.db.models. В моем случае поле name это текстовое поле CharField, поле karma это число float. Список всех полей (Field types) есть в официальной документации.
У каждого поля есть опции (Field options) — в коде выше опция это max_length = 20. Опции зависят от полей, которые вы создаете в базе — например, max_length = 20 это максимальная длина в символах поля name в базе. В документации по ссылке выше также описаны опции для всех полей.
На основе этого кода Django сам создаст таблицу в базе данных и то, что я назвал полями в классе будут столбцами в этой таблице. Django дает вам также удобные команды в python как получать или записывать значения в базу данных. Все делается с помощью методов models.Model а также абстракции «Manager», отвечающей в Django за коммуникацию с базой данных (в данном посте я эти абстракции детально не рассматриваю). Например, CustomUser.objects.filter(name=«Михаил») вернет всех пользователей с именем «Михаил».
Такая связь между строками в базе данных и объектами (экземплярами, инстансами) в Python называется Object-relational mapping — в нашем случае Django-ORM.
А наши модели повторяют структуру базы данных и при этом являются классами в Python. Это значит, что к моделям (классы в Python) можно добавить методы. Например, продолжая логику сайта Хабр, я могу добавить метод для изменения кармы:
Тут other — это другой пользователь. Как вы знаете здесь определенная логика добавления кармы. Всю эту логику я могу, например, создать в указанном методе.
В Django вы думаете какие таблицы хотите создать в своей базе и потом просто создаете классы python по примеру выше.
Слой виды
Следующим важным, на мой взгляд, слоем является слой видов (views). Ваши модели это некоторые абстракции, с которыми вам удобно работать или они интуитивно понятны. Но, когда вы хотите что-то показать пользователям, то, возможно, вас будут интересовать иные абстракции.
Например, вы создали три модели в Django: CustomUser, Article и Advertisement с разными полями. Модель Article это статья сайта, Advertisement — это реклама, которую вы показываете на сайте, CustomUser — зарегистрированный пользователь сайта.
Когда вы захотите создать вебстраницу со статьей, то вам понадобятся данные сразу из нескольких ваших моделей — разумеется вы хотите показать все поля в самой статье (название, содержание и т.д.), вы, скорее всего, также хотите показать какую-то рекламу рядом с этой статьей. Причем реклама зависит не от содержания статьи а от поведения пользователя CustomUser. При таком подходе будет нужна какая-то логика — как собирать данные. Так, слой view в данном случае и будет подходящим местом для этой логики. Тут можно собрать все данные, которые будут относиться к тому, что вы хотите показать.
Есть два типа видов view в Django — функциональный и классовый.
Функциональный вид это просто Python функция с аргументом request — это запрос к вашему сайту. В нем содержится информация о пользователе, типе запроса и многом другом. На основе этой информации вы формируете ответ и возвращаете его в своей функции.
Еще один тип view — классовый. Он позволяет создавать виды не на основе функций, а виды как экземпляры классов. Тут Django предоставляет также кучу всяких облегчающих жизнь классов и функций. Предположим, вы хотите создать вид на основе статьи Article:
Классовый вид на основе DetailView автоматически соберет всю информацию модели Article и затем отправит ее в следующий слой Django:
Слой шаблоны
В коде выше template_name это переменная для названия html шаблона, который будет использован для формирования веб страницы, которая и будет показана пользователю. Вот пример кода из такого шаблона:
10 полезных советов для начинающих изучать Django
1. Используйте относительные пути в конфигурации
2. Используйте тег
Вместо того, чтобы хардкодить ссылки, попробуйте использовать обратно совместимый тег <% url %>. Это даст вам абсолютный URL, но если проект будет перемещен, ссылки остануться актуальными.
По сути <% url %>берет имя представления и его параметры и делает реверсивный просмотр, чтобы вернуть запрошенный URL. Если вы внесете изменения в urls.py, ссылки не сломаются.
3. Используйте админку Django для ваших приложений на PHP
Одно из достоинств Django его система авторизации пользователей, которая встроена в ядро Django. Ее очень легко настроить и она содержит в себе удобную систему для авторизации пользователей и задания необходимых настроек.
Эта система авторизации настолько хороша, что многие предлагают использовать ее как админку для приложений на PHP.
4. Используйте отдельный сервер для обработки статики
Django позволяет вам располагать статические файлы в dev-окружении, но не в вашем production-окружении.
Django спроектирован так, что бы спасти вас от себя самого. Если вы попытаетесь использовать статические файлы с того же экземпляра Apache, что обслуживает Django, вы потеряете в производительности.
Apache переиспользует процессы между каждым запросом, поэтому, если однажды процесс закешировал весь код и библиотеки для Django, они остаются в памяти. И если вы не используете этот процесс для того, чтобы
обработать запрос Django, вся эта память будет использована зря.
В случае если вы используете отдельный сервер (или virtualhost) для обработки статики, производительность вашего приложения не пострадает.
5. Используйте Django debug toolbar.
Инструменты для отладки несут неоценимую помощь в любом языке. Они ускоряют процесс разработки помогая находить ошибки и потенциальные проблемы которые могут возникнуть.
Django debug toolbar позволяет просмотреть все выполненные SQL запросы в процессе рендеринга представления и вы также можете просмотреть stacktrace для любого из них.
6. Django юнит-тестирование
Юнит-тестирование хороший способ убедится что ваши изменения в коде работают так, как ожидается и не ломают предыдущий код. Одна из прекрасных возможностей Django — это то, что писать юнит тесты невероятно просто. Django предлагает возможность использовать doctest или unittest прямо из коробки, а документация Django содержит отличные обучающие материалы и примеры кода, как настроить юнит тесты, чтобы обнаружение багов стало еще более простым занятием.
7. Визуализация моделей
Установите Django Command Extensions и pygraphviz и затем используйте следующую команду чтобы получить удобную визуализацию моделей проекта в Django:
8. Virtualenv
Virtualenv + Python = палочка-выручалочка. Virtualenv будет изолировать настройки Python/Django для каждого отдельного проекта. Это значит, что изменения одного сайта не затронут другие сайты. Также это может оказаться удобным, когда на сервере необходимо держать разные версии Django или python.
9. Используйте Memcache
Когда низкая производительность может стать проблемой, вы скорее всего захотите установить какую-либо систему кеширования. Django предлагает множество вариантов для кеширования, но лучшим из них на сегодняшний день является memcached.
Установить и использовать memcached весьма просто, если вы используете модуль cmemcache. После того как модуль будет установлен, вам нужно внести одну строку в конфигурацию, чтобы ваши страницы начали выдаваться еще быстрее.
10. Автозагрузка кастомных тегов, которые можно использовать во всех шаблонах
Если добавить это в модуль который загружается по умолчанию (settings.py,urls.py,every app models.py), у вас будут доступны все теги и фильтры из вашего кастомного модуля в любом шаблоне, без использования <% load custom_tag_module %>.
Аргументом к template.add_to_builtins() может быть путь к любому модулю; ваш кастомный модуль не обязательно должен быть привязан к какому то определенному приложению.
Например, это так же может быть модуль расположенный в корневом каталоге проекта (например: ‘ project.custom_tag_module ‘).
Стоит ли изучать Django в 2020?
Если вы начинающий программист, и задаетесь вопросом: должен ли я изучить Django? Короткий ответ — да.
Если вам потребуется реализовать вашу идею с минимальными затратами и быстро — Django подходящий инструмент. Он бесплатен, свободен и позволяет сделать разработку web-проектов еще проще. Django лучшее решение для разработки прототипов приложений, поскольку он включает все необходимое для создания необходимого функционала прямо из коробки. Например, админка может быть подключена одной строчкой кода.
Если вы разработчик уже знакомый с Python, и находитесь в поисках фреймворка для бэкенда вашего приложения или сайта, Django также будет хорошим выбором.
Фреймворк содержит в себе библиотеки и инструменты позволяющие проводить различные операции и эффективно обрабатывать большое количество запросов пользователей в реальном времени.
Поэтому процесс разработки становится быстрым, так как вам не нужно создавать каждый компонент с нуля.
Преимущества Django
1. Быстрый
Разработчики сделали фреймворк с учетом того, что бы он был простым и в то же время быстрым. Он содержит в себе библиотеки, которые позволят вам не изобретать колесо заново или создавать проект с нуля.
2. Безопасный
Когда речь заходит о безопасности, фреймворк позволяет не наступать на грабли и избежать многих проблем с безопасностью, таких как SQL-иньекции, XSS, CSRF, из-за возможных ошибок программиста.
3. Панель администрирования
В фреймворке сразу присутствует панель администрирования и система авторизации, которая позволяет сэкономить время на управлении пользователями, и создании отдельной панели администрирования для бэкенда.
4. Масштабируемый
Фреймворк подходит для проектов с разной степенью нагруженности, и если небольшой проект в будущем может вырасти, никаких проблем — Django прекрасно масштабируется под большие нагрузки.
5. Data science и аналитика
Мы уже знаем, что Django сделан на Python, а Python известен как прекрасный инструмент для создания проектов с использованием искусственного интеллекта и машинного обучения. Следовательно, если вы планируете интегрировать в ваш проект машинное обучение или анализировать и обрабатывать большие объемы информации, то вы определенно должны попробовать Django.
6. Поддержка сообществом
Вокруг Django существует довольно большое и активное сообщество, а сам фреймворк имеет богатую и удобную документацию.
Быстрый старт
Чтобы сразу быстро начать кодить на Джанго командой и тестировать, я собрал и выложил образ VPS в маркетплейсе с пустым проектом Django 3.1.3 и
Стоимость такого сервера будет 769 рублей в месяц – 538 рублей, при оплате за год.
И напишите свои любимые лайфхаки при работе с Django в комментариях — попробуем собрать пост советов.
Эффективный Django. Часть 1
Оглавление
Введение ⇧
«Связный» код — это код, который сосредоточен на выполнении одной вещи, только одной единственной вещи. Это значит, что когда вы пишете функцию или метод — написанный вами код должен делать что-то одно и делать это хорошо.
Это непосредственно относится к написанию тестируемого кода: код, который делает много вещей, достаточно часто является чересчур сложным для тестирования. Когда я ловлю себя на мысли: «Хорошо, этот кусок кода слишком сложен, чтобы писать для него тесты — это просто не стоит потраченных усилий» — вот сигнал к тому, чтобы вернутся назад и сосредоточиться на упрощении. Тестируемый код — такой код, который позволяет просто писать для него тесты; код, в котором легко найти проблемы.
И наконец, мы хотим писать масштабируемый код. Это означает не просто масштабировать его в терминах исполнения, но так же увеличивать в терминах команды и командного понимания. Хорошо протестированные приложения проще для понимания другими (и проще для изменения ими), что подразумевает большую возможность улучшить ваше приложение, путем добавления новых инженеров.
Моя цель — убедить вас в важности этих принципов, и предоставить примеры того, как следуя им, построить более стойкое Django-приложение. Я собираюсь последовательно пройти через процесс построения приложения для управления контактами, рассказывая про решения и стратегию тестирования, которые я использую.
Эти документы являются сочетанием заметок и примеров подготовленных для PyCon 2012, PyOhio 2012, и PyCon 2013, а также для web-разработки Eventbrite. Я все еще работаю над объединением их в один документ, но надеюсь вы найдете их полезными.
Примеры кода для этого руководства доступны на github’е. Отзывы, предложения и вопросы можете присылать на nathan@yergler.net.
Этот документ доступен на сайте, а также в форматах PDF и EPub.
Видео этого руководства с PyCon можно посмотреть на YouTube.
Глава 1. Приступая к работе ⇧
1.1. Ваша среда разработки
Изоляция означает, что вы не сможете случайно воспользоватся инструментами или пакетами установленными вне вашего окружения. Это особенно важно, когда подобное происходит с чем-то, похожим на пакеты Python с расширениями написанными на C: если вы используете что-то установленное на системном уровне и не знаете об этом, то при развертывании или распространении своего кода вы можете обнаружить, что он работает не так как предполагалось. Инструменты наподобие virtualenv могут помочь создать нечто похожее на изолированную среду.
Ваша среда предопределена, если вы уверены в том, на какую версию ваших зависимостей вы полагаетесь и сможете ли вы наверняка воспроизвести системное окружение.
1.1.1. Изоляция
1.1.2. Предопределенность
1.1.3. Сходство
1.2. Настройка вашего окружения
1.2.1. Создание чистого рабочего пространства
Примечание переводчика:
Для начала создадим каталог ( tutorial ), в котором будем работать:
В каталоге venv будет находится наше виртуальное окружение, а в каталоге project — Django-проект
1.2.2. Создание файла зависимостей
Создайте файл requirements.txt в директории tutorial с единственной строкой (зависимостью) в нем:
Примечание переводчика:
В случае, если вы хотите использовать последнюю версию Django (1.7 — на момент написания перевода) — вместо строки Django==1.6.7 оставьте просто Django — pip установит последнюю доступную версию.
1.2.3. Установка зависимостей
А теперь мы можем использовать pip для установки зависимостей:
1.3. Начало проекта Django
Когда здание находится в процессе постройки, строительные леса часто используются для поддержания структуры до того как строительство будет завершено. Строительные леса могут быть временными или они могут служить частью фундамента здания, но несмотря на это, они представляют некоторую поддержку когда вы только начинаете работу.
Django, как и многие web-фреймворки, представляет скаффолдинг для вашей разработки. Это происходит при помощи принятия решений и предоставления отправной точки для вашего кода, что позволяет вам сосредоточится на проблеме, которую вы пытаетесь решить, а не на том, как разобрать HTTP-запрос. Django предоставляет скаффолдинг как для работы с HTTP, так и для работы с файловой системой.
1.3.1. Создание проекта
Созданный проект имеет следующую структуру
1.3.2. Скаффолдинг проекта
1.3.3. Создание приложения
Созданное приложение имеет следующую структуру:
Примечание переводчика:
На текущий момент наша директория
/tutorial/ содержит файл зависимостей ( requirements.txt ), директорию с виртуальным окружением ( venv/ ), один проект ( project/addressbook ), одно приложение ( project/contacts ) и имеет следующее содержание:
Глава 2. Используем модель ⇧
2.1. Конфигурирование базы данных
Для использования SQLite нам нужно указать движок ( ENGINE ) и имя базы ( NAME ). SQLite интерпертирует имя базы как имя файла для базы данных:
2.2. Создание модели
Модели Django отображают (грубо говоря) таблицы базы данных, и предоставляют место для инкапсулирования бизнес-логики. Все модели являются наследниками базового класса Model и содержат поля определений. Давайте создадим простую модель Contacts для нашего приложения в файле contacts/models.py :
После того, как вы создали модель, необходимо дополнить вашу базу данных новыми таблицами. Команда Django syncdb смотрит установленные модели и создает (если нужно) таблицы для них:
Примечание переводчика:
Django предложит создать суперпользователя для андминки, которая включена в этой версии по умолчанию. Воспользуйтесь его предложением.
Примечание переводчика:
Если вы используете Django версии 1.7 и выше — вывод будет следующий:
Однако нашей таблицы с контактами нигде не видно. Причина этого состоит в том, что нам нужно еще указать проекту использовать приложение.
После этого запустите syncdb снова:
Примечание переводчика:
Для Django версии 1.7 и выше вам нужно будет запустить сначала команду makemigrations — для создания миграций на основе изменений в моделях, а после этого выполнить команду migrate — для того чтобы применить созданные миграции.
Примечание переводчика:
Вывод для Django 1.7 и выше:
Заметьте, что Django создает таблицу с именем contacts_contact : по умолчанию Dj ango дает таблицам имена используя комбинацию имени приложения и имени модели. Вы можете изменить это с помощью опций модели Meta.
2.3. Взаимодействие с моделью
Теперь, когда модель синхронизирована с базой данных мы можем взаимодействовать с нею используя интерактивную оболочку:
Здесь использовалось несколько новых штук. Во-первых, команда manage.py shell запускает для нас интерактивную оболочку Python’а с правильно установленными путями для Django. Если вы попробуете запустить интерпретатор Python и просто импортировать ваше приложения, будет выброшено исключение, потому что Django не знает, какие настройки использовать, и не может отобразить экземпляры модели на базу данных.
2.4. Написание тестов
Вы можете запустить тесты для вашего приложения используя команду manage.py test :
Если вы запустите это, то увидите что выполнилось около 420 тестов. Это удивляет, так как мы написали только один. Произошло это потому, что по умолчанию Django запускает тесты для всех установленных приложений. Когда вы добавляли приложение contacts в наш проект, то могли увидеть, что там по умолчанию были добавлены несколько встроенных приложений Django. Дополнительные 419 тестов были взяты оттуда.
Примечание переводчика:
В нашем случае (при использовании версии Django 1.6.7) предыдущий абзац несколько устарел: запустится только один тест — тот который мы создали. Вывод команды будет такой как указано ниже.
Если же вы захотите запустить тесты для определенного приложения — укажите имя приложения в команде:
2.5. Резюме
Примечание переводчика:
Для того чтобы протестировать наше, пока еще пустое, приложение нужно выполнить следующую команду:
Это запустит встроенный сервер, функционал которого любезно предоставляет нам Django. В параметрах после runserver указывается ip-адрес и порт, который будет слушаться работающим сервер. В нашем случае сервер будет принимать запросы от всех ip-адресов при обращении на 8080 порт.
В каких случаях стоит использовать Django (а в каких не стоит)
Давайте поможем разработчикам разобраться, подходит ли фреймворк Django для их следующего проекта. Вполне вероятно — подходит.
Не стоит хвататься за определенный язык программирования или фреймворк лишь потому, что вы пользовались им в вашем предыдущем проекте, или просто потому что он вам хорошо знаком. Так дела не делаются.
Прежде чем приступать к новому проекту, следует оценить, какой язык или фреймворк лучше всего подойдет вам для достижения желаемого результата. Что для вас наиболее важно? Безопасность, скорость разработки, масштабируемость, универсальность, поддержка?
Лучше принять информированное решение перед тем как приступать к работе, чем потом раскаиваться в поспешном (или, хуже того, навешивать на проект костыли в процессе реализации – из-за того, что заранее не озаботились его поддержкой).
Я много лет работал с разными технологиями, имел дело как с мобильной, так и с веб-разработкой, и считаю, что Django предлагает такой полноценный набор возможностей, каких нет ни в одном другом веб-фреймворке.
Понимаю, это громкое заявление. Позвольте мне его обосновать.
«На Django основано множество сайтов, используемых самым активным образом, в частности, Instagram и Pinterest. Даже Facebook использует Django для многих своих утилит. Django зародился в издательской среде, поэтому неудивительно, что данный фреймворк используется на таких сайтах как The Washington Post и Smithsonian Magazine.” — Амит Ашвини, Вице-президент по маркетингу @ Zibtek
Общий взгляд: когда использовать Django
Если хотя бы несколько из нижеприведенных тезизов – про вас (и в списке нет тезисов, с которыми вы категорически не согласны), то, вполне вероятно, Django хорошо подойдет для вашего проекта.
Если вы – веб-разработчик, и уже знаете, как веб устроен, то работа с Django пойдет для вас сравнительно гладко. Необходимо понимать, как структурируется Django, и некоторые другие вещи, конечно, тоже – и считайте, что вы готовы.
Сайты, работающие на фреймворке Django
Вы еще сомневаетесь, стоит ли тратить свое драгоценное время, чтобы напрактиковаться с Django? Для начала давайте обсудим, по каким причинам Django может НЕ ПОДОЙТИ для вашего проекта:
Когда не стоит использовать Django
Причины использовать Django
Фреймворк Django написан на Python:
Знаю, вам это известно.
Поэтому воспользуюсь случаем и подчеркну некоторые ключевые достоинства Django, которые он унаследовал от Python. Буду краток.
Python – один из самых популярных и быстрорастущих языков программирования в мире.
Изучить Python действительно очень просто. Обычно современные разработчики учат первым именно этот язык.
Вышесказанное совершенно не означает, что этот язык – только для начинающих. Python используется и в ультрасовременных технологиях. Python активно применяется в технологическом стеке многих компаний-гигантов, в том числе, Google.
Язык Python отлично подходит для разработки инструментов веб-скрапинга.
Он хорошо взаимодействует с другими языками.
Разработка на Python не означает, что вы будете вынуждены все и вся писать только на Python.
Вы вполне сможете пользоваться библиотеками для многих других языков, в том числе, C/C++/Java.
Python портируемый, его удобно читать.
Python даже может работать на JVM. Познакомьтесь с Jython.
Python широко используется в таких востребованных технологиях как Большие Данные и Машинное обучение.
Вы получаете доступ к огромной библиотеке PyPI.
У Django “Все включено”
“Все включено” означает, что Django «из коробки» оснащен большинством библиотек и инструментов, нужных в распространенных практических ситуациях. Перечислю: Django ORM, промежуточное ПО, аутентификация, HTTP-библиотеки, многосайтовая поддержка, i18n, Django Admin, движок-шаблонизатор, т.д. – и это еще не «все». Ни один другой известный мне фреймворк не предоставляет столь широкой поддержки сразу.
Некоторые считают такое обстоятельство “минусом”, а другие – «плюсом». Каждая сторона права по-своему, и я в некоторой степени согласен с обеими.
Это минус, поскольку в такой ситуации фреймворк превращается в монолит.
Я считаю, что, если вам требуются эти возможности, приводящие к формированию монолита, то вам так или иначе придется воспользоваться какой-то другой библиотекой (или написать ее самостоятельно).
Почему бы в таком случае не воспользоваться инструментом, в котором все это уже есть, проверено в боях, функционирует на крупнейших сайтах, активно разрабатывается и обеспечено поддержкой сообщества?
Если вам не требуется большинства возможностей, предлагаемых в Django, то лучше остановиться на каком-нибудь микрофреймворке.
Не изобретать велосипед – вы помните? Потратьте ваше время на то, что действительно важно, а Django пусть сделает все остальное.
Django Admin
Хотя, я и упомянул этот элемент в предыдущем разделе, он заслуживает более пристального внимания. Во многих фреймворках, в частности, Laravel, Yii, т.д., предпринимались попытки упростить работу с админкой. Мне доводилось разрабатывать множество проектов в разных фреймворках, но ни один из них и близко не сравнится с Django по удобству работы с панелью администратора.
Некоторые считают, что Django Admin недостаточно гибок, и для подстройки любой его части под свои нужды требуется приложить массу усилий. На первых порах работы с Django я склонен был с этим соглашаться, но со временем, разобравшись во фреймворке, разубедился в этом. Да, там присутствует своя кривая обучения, но ни секунды, что вы ей уделите, не будет потрачено зря.
На самом деле, Django Admin очень хорошо структурирован. В некоторых моих проектах я использовал админку Django «как есть», а в других полностью заменял ее собственными шаблонами, которые разрабатывал с нуля. В любом случае, на это потребовалось не больше времени, чем на разработку с любым другим известным мне фреймворком.
Основной плюс? Вы получаете «из коробки» права доступа и аутентификацию. На разработку всего этого с нуля у вас ушли бы недели (или, как минимум, несколько дней).
Принцип DRY (Не Повторяйся)
Мне известно множество фреймворков, сторонники которых утверждают, что те действительно соответствуют принципу “DRY”. Я работал с многими такими фреймворками, но ни в одном из них принцип «DRY» не реализован как следует.
К сожалению, в большинстве фреймворков принципу “DRY” просто не уделяют достаточного внимания. На мой взгляд, если вы пишете приложение, которое собираетесь регулярно обновлять (а это можно сказать о большинстве современных приложений), то вы должны следовать принципу DRY во избежание проблем.
Так, в Laravel приходится писать валидацию для каждой процедуры отдельно. Такова же ситуация и с большинством других фреймворков. Чтобы ваш код соответствовал принципу DRY, нужно потрудиться. Сложно это отслеживать, особенно если вы работаете в команде.
В свою очередь, фреймворк Django спроектирован таким образом, что нарушить принцип DRY там обычно выходит только нарочно.
Так быть не должно, верно? Рассмотрим пример.
Вот как в Django устроена валидация и миграция базы данных
Создаем класс Model с требуемыми полями. Указываем все необходимые нам дополнительные валидации и ограничения.
Миграции генерируются единственной CLI-командой: `python manage.py makemigrations`.
Изменения вносятся в базу данных единственной CLI-командой: `python manage.py migrate`.
Валидации и ограничения автоматически проверяются при каждой CRUD-операции — идет ли речь о Django Admin или о Django REST Framework. Писать валидации заново вам не придется.
Тот же самый класс модели используется для генерации представлений Django Admin CRUD. Не требуется дописывать никаких собственных HTML/CSS.
Сравните эти условия с любым другим фреймворком – и, думаю, вам бы нигде не удалось сделать ничего подобного всего в несколько следующих строк кода:
Здесь речь не только о том, чтобы “не повторяться”. Такой подход уберегает вас от багов в перспективе. Все мы оказывались в ситуациях, когда довелось изменить что-то в одном месте, а в другом месте заменить забыли – и это выяснилось лишь после того, как у множества пользователей начались проблемы.
В Django, возвращаясь к вышеприведенному коду, если вам когда-нибудь придется заменить `max_length` поля на что-нибудь другое – просто сделайте это здесь. Изменение автоматически применится к валидации всех маршрутов и к базе данных.
Объектно-реляционное отображение в Django
Django предоставляет полнофункциональный механизм ORM «из коробки».
Я работал со множеством инструментов ORM в разных технологиях, в том числе, в Eloquent, greenDAO, Yii AR, т.д. Во всех из них простейшие запросы обрабатываются довольно хорошо, но рано или поздно мне приходилось писать те или иные запросы с нуля, поскольку механизм ORM не справлялся с конкретным практическим случаем.
С Django ORM в такие ситуации я пока не попадал. Он сработан настолько хорошо, что вы просто можете забыть, что работаете с запросами к базе данных. Именно таким и должно быть объектно-реляционное отображение. Ниже приведены некоторые примеры Django ORM:
Стремительная разработка
Этим любят похвастаться создатели практически любого веб-фреймворка, и, пожалуй, все они действительно правы – смотря какой смысл мы вкладываем в слово «стремительная».
Правда, с Django некоторые вещи делаются уморительно быстро. Вы уже видели, как легко мы смогли определить UI админки, таблицу базы данных и выполнить валидацию.
Это была всего лишь верхушка айсберга.
В принципе, стремительная разработка – это не фича как таковая, а лишь органичное следствие присутствующих в Django DRY, ORM, шаблонизатора и философии «все включено».
Безопасность фреймворка Django
Давайте признаем, иногда разработчики ленятся. Я – так точно. Время от времени я прокрастинирую, откладывая решение критически важных задач. Тут-то и могут возникнуть различные уязвимости.
Мне особенно нравится, что Django не идет на послабления по поводу безопасности, чтобы ускорить темп разработки. Функции безопасности активируются по умолчанию, поэтому совершенно не важно, ленивы вы или нет.
Опенсорс, отличная документация, огромное сообщество и пр.
Поскольку Django – опенсорсный и безумно популярный фреймворк, вокруг него сформировалось отзывчивое сообщество. Думаю, вы в курсе, каковы достоинства свободного ПО – так вот, все они присущи и Django.
Официальной документации Django более чем достаточно любому разработчику. Если застрянете – найти решение не составит труда.
У вас уже могло сложиться впечатление, что в Django создано множество собственных библиотек, поэтому, возможно, удивитесь, что специальной библиотеки для тестирования здесь не сделано. Нет, не подумайте, что фреймворк Django не поддерживает тестирование – поддерживает, еще как. Просто, следуя принципу «Не повторяйся» было бы бессмысленно разрабатывать библиотеку для тестирования, когда отличная библиотека такого рода уже есть в самом Python. Django отлично с ней взаимодействует. Кроме того, он очень хорошо сочетается и со сторонними библиотеками, например, pytest.
Современное состояние Django и другие популярные фреймворки
Итак, я по максимуму постарался осветить те проблемы, с которыми сталкивался при работе с другими фреймворками и сравнить эти фреймворки с Django. Поработав с Yii, CodeIgniter, WordPress, CS-Cart, Laravel, т.д., я пришел к выводу, что Django гораздо лучше любого из них.
Однако, это только мое мнение.
Если вам нравится статистика, то вот ежегодное исследование Stack Overflow, где Django фигурирует в числе самых излюбленных и востребованных фреймворков:
Кроме вышеупомянутого опыта работы с PHP, я также рапзрабатывал приложения под Android на Java, клиентские приложения на React.js. Во всех этих случаях я потратил изрядное количество времени на рефакторинг базы кода, подыскивая наилучшую архитектуру, через пару месяцев увязая в проблемах с масштабируемостью и вновь принимаясь за рефакторинг.
Недавно я переписал с Laravel на Django одно приложение, которое было у меня в продакшене более года. Мне удалось развернуть новую базу кода менее чем за 10 дней, написав для этого минимальное количество кода (говорю же: сложность уменьшается!) В обратном направлении подобная операция определенно заняла бы более месяца.
Если вы попытаетесь напрямую сравнивать другие фреймворки с Django, это вам ничего не даст.
Контроль производительности может показать, что фреймворк на Java быстрее Django. Вы можете хорошо разбираться в PHP, так что, возможно, разработка приложения на Django пойдет у вас быстрее, чем на знакомом вам PHP-фреймворке. В случае с совсем простым приложением настройка Django может показаться вам слегка утомительной – конечно, гораздо проще написать файл со скриптами. Результаты опросов могут разниться в зависимости от того, среди какой аудитории они проводились.
Однако, здесь мы рассуждаем не только о фреймворках, относящихся к другим технологиям. Даже если вы знакомы c Python, возможно, микрофреймворк Flask покажется вам более удобным и желательным. Придется задуматься, на котором из них остановиться.
Мой совет – просто не сравнивайте их.
Вывод
На мой взгляд, в Django удалось идеально сбалансировать производительность, архитектуру, уровень сложности при разработке, безопасность и масштабируемость.
Если вы начинаете писать проект с нуля – настоятельно рекомендую попробовать сделать его с Django.