Django… Все мы знаем о популярности этого фреймворка Python. Django стал первым выбором разработчиков для создания своих веб-приложений. Это бесплатная среда Python с открытым исходным кодом. Django может легко решить множество общих задач разработки. Он позволяет создавать гибкие и хорошо структурированные веб-приложения.
Многие общие функции Django, такие как встроенная панель администратора, ORM (инструмент объектно-реляционного сопоставления), маршрутизация, шаблоны, упростили задачу для разработчиков. Им не нужно тратить так много времени на реализацию этих вещей с нуля.
Одна из самых потрясающих функций Django — это встроенная панель администратора. С помощью этой функции вы можете настроить множество вещей, таких как список управления доступом, разрешения на уровне строк и действия, фильтры, заказы, виджеты, формы, дополнительные помощники URL-адресов и т. Д.
Django ORM «из коробки» работает со всеми основными базами данных. Он поддерживает все основные SQL-запросы, которые вы можете использовать в своем приложении. Движок шаблонов Django также очень, очень гибкий и в то же время мощный. Даже в Django доступно множество функций, разработчики по-прежнему делают много ошибок при создании приложения. В этом блоге мы обсудим некоторые типичные ошибки, которых следует избегать при создании приложения Django.
- 1. Использование глобальной среды Python для зависимостей проекта
- 2. Избегайте закрепления зависимостей проекта в файле » requirements.txt»
- 3. Использование функций Python в старом стиле вместо представлений на основе классов
- 4. Написание логики приложения в представлениях вместо модели
- 5. Грязный и неуправляемый файл настроек
- 6. Плохая структура приложения и неправильное размещение ресурсов
- 7. Путаница между STATICFILES_DIRS и STATIC_ROOT в Django
- Вывод
1. Использование глобальной среды Python для зависимостей проекта
Использование глобальной среды для зависимостей проекта может вызвать конфликты зависимостей. В Python нельзя одновременно использовать несколько версий пакета. Это создаст проблему, если для разных проектов требуются разные несовместимые версии одного и того же пакета. Есть много вариантов изолировать вашу среду. Ниже приведены наиболее распространенные способы…
- virtualenv
- virtualenvwrapper
- Виртуальные машины
- Контейнеры
2. Избегайте закрепления зависимостей проекта в файле » requirements.txt»
Когда вы начинаете с проекта Python, начните с изолированной среды с файлом «require.txt». Когда вы устанавливаете пакеты через pip / easy_install, не забудьте добавить их в свой файл «requirements.txt». Позже, когда вам нужно будет развернуть свой проект на сервере, вам будет проще.
Различные версии пакетов предоставляют разные модули, функции или параметры. Если в вашей зависимости произойдут незначительные изменения, это может привести к поломке вашего пакета. Поэтому важно закрепить конкретную версию ваших зависимостей в файле «require.txt». Есть очень хороший инструмент пип-инструменты, доступные в Python. С помощью доступных в нем инструментов командной строки вы можете легко управлять своими зависимостями.
Этот инструмент автоматически генерирует файл Requirment.txt, который закрепляет все ваши зависимости и все ваше дерево зависимостей. Кроме того, сохраните резервную копию файла зависимостей. Сохраните копию в своей файловой системе, в управляемой папке Git, папке S3, FTP и SFTP.
3. Использование функций Python в старом стиле вместо представлений на основе классов
В Python разработчики в большинстве случаев избегают использования представлений на основе классов из-за их сложности. В течение некоторого времени может быть хорошей идеей использование функции Python в файле views.py приложения (например, для тестов или служебных представлений).
Представления на основе классов предоставляют абстрактный класс, реализующий общие задачи веб-разработки. Вы можете получить преимущество использования структурированного API наряду с преимуществами объектно-ориентированного программирования. Ваш код становится более понятным и читаемым. Вы можете расширить свой CBV для своего представления и переопределить свойства или функции класса.
В своем проекте вы можете использовать разные миксины и можете переопределить базовое поведение CBV для создания контекстов представления, проверки авторизации на уровне строк, автоматического создания путей к шаблонам из структуры вашего проекта.
4. Написание логики приложения в представлениях вместо модели
Написание логики в представлениях делает представление вашего приложения «толстым», а модель — «тонким». Избегайте этой ошибки и всегда пишите логику в своих моделях вместо представлений. Вы можете разбить логику на небольшие методы и записать их в модели. Вы можете использовать его несколько раз из разных источников всего в нескольких строках кода.
5. Грязный и неуправляемый файл настроек
Часто бывает, что во время работы над реальным проектом ваш файл настроек вырастает до более чем 600-700 строк кода. Этот огромный и беспорядочный файл становится трудным в обслуживании, особенно когда ваша среда разработки, производства и подготовки требует специальной настройки. Вы можете разделить файл конфигурации вручную и создать собственные загрузчики.
6. Плохая структура приложения и неправильное размещение ресурсов
Всякий раз, когда вы создаете приложение с помощью Django, оно содержит несколько приложений. Эти приложения отвечают за выполнение определенной задачи. По сути, эти приложения представляют собой пакеты Python, содержащие как минимум файлы __init__.py и models.py. В последней версии Django вам больше не требуется версия Django. В вашем приложении достаточно __init__.py.
Ваше приложение Django построено на различных модулях Python, таких как модели, администраторы, представления, URL-адреса, модели, формы, теги шаблонов и т. Д. Вы можете разделить свое приложение на повторно используемую логику приложения.
Всегда давайте папке проекта конкретное имя и помещайте свое приложение в project / apps /. После этого вы можете поместить зависимости вашего приложения в их собственные подпапки.
7. Путаница между STATICFILES_DIRS и STATIC_ROOT в Django
В Django статические файлы в основном содержат JavaScript, CSS, изображения, шрифты и т. Д. Они собираются в общедоступный каталог в процессе развертывания. python manage.py runserver ищет статические файлы, используя параметр STATICFILES_FINDERS. Если происходит сбой, Django пытается найти файл с помощью django.contrib.staticfiles.finders.AppDirectoriesFinder. Это заглянет в статическую папку каждого установленного приложения в проекте. Вы можете писать многоразовые приложения с собственными статическими файлами.
В Django, используя команду статического управления python manage.py collectstatic, вы можете пройти через STATICFILES_FINDERS и скопировать файлы из статических папок, а также из STATICFILES_DIRS в каталог, указанный в параметре STATIC_ROOT.
Вывод
В этой статье мы упомянули семь ошибок, но в Django есть много вещей, о которых вам нужно позаботиться. При создании проекта в Django следуйте рекомендациям по написанию кода в своем проекте. Все имеет значение, от определения URL-адреса до создания представления или определения модели до полной структуры папок. Вначале это будет сложно, но по мере продвижения вы увидите улучшения в себе. Совершать эти ошибки — нормально, но если вы продолжите смотреть на хороший проект Django, вы обязательно овладеете им.
