За последний год я полюбил одну из самых популярных веб-фреймворков Python, Django; Веб-фреймворк для профессионалов с соблюдением сроков. Основная цель Django - упростить создание сложных веб-сайтов на базе баз данных. Это избавило меня от многих головных болей при разработке Buza Answers. Вот несколько советов, которые я не нашел в онлайн-уроках, но помогли мне на этом пути:
Старый но золотой
Одна из причин, по которой я не решался использовать Django, заключается в том, что я хотел использовать новый, более крутой фреймворк, но это просто ненужное техническое влияние. Django - это мощный, хорошо документированный и поддерживаемый фреймворк. Он зрелый, поэтому в нем меньше ошибок и больше вопросов о переполнении стека. Вдобавок к этому Django используется крупными организациями, такими как Instagram, Spotify, Dropbox и YouTube.
Джанго или Flask?
Когда я начал искать веб-фреймворк, моими главными двумя вариантами были Flask и Django. Я прочитал довольно много сообщений в блогах, в которых подчеркиваются различия между двумя фреймворками. Основные сравнения основаны на скорости, сложности и некоторых других производственных показателях, которые для меня не имели смысла. Эти показатели не особо помогли, потому что в каждом блоге были разные выводы.
Теперь я понял, что метрики не так важны, когда дело доходит до выделения двух фреймворков, потому что на самом деле они очень разные. Flask не заменяет Django. Это все равно, что сравнивать Бейонсе и Рианну, у них очень разные ниши. Django - это фреймворк полного стека, то есть вы можете использовать его для базы данных, логики приложения и создания HTML-шаблонов. Это упрощает создание веб-приложений. С другой стороны, Flask - это фреймворк микросервис. Это означает, что у него нет уровня абстракции базы данных, проверки формы или шаблонов. Flask дает вам более детальный контроль над каждым аспектом вашего приложения, в то время как Django дает вам несколько строгих рекомендаций. На свой страх и риск вы можете использовать оба фреймворка для своего приложения.
Отпустите manage.py
Многие онлайн-руководства по Django предложат вам запускать такие команды, как `./manage.py migrate` или` python manage.py collectstatic`. Это заставило меня подумать, что manage.py - это сложный и длинный скрипт, который творил много волшебства, но однажды я открыл его, и все, что он делает, - это установка переменной окружения DJANGO_SETTINGS_MODULE. Это сообщает Django, где найти настройки вашего проекта, чтобы он мог выполнять такие задачи, как createapp, migrations и runserver. Manage.py полезен, когда вы только начинаете, поскольку избавляет от необходимости устанавливать переменную среды каждый раз при перезапуске виртуальной среды, но также может вызвать множество проблем. Если вы переименуете имя проекта, измените каталог приложения или измените имя основного файла настроек; он может не установить правильный DJANGO_SETTINGS_MODULE. Это заблокирует вам возможность запускать задачи django.
Альтернативой является установка вручную DJANGO_SETTINGS_MODULE = project.project_settings_filename в вашей среде, чтобы сэкономить время, вы можете поместить указанную выше команду в файл .env. Теперь вы можете заменить ./manage.py на django-admin в терминале / командной строке, например `django-admin runserver`. Это также позволит вам использовать разные настройки для разных команд django: django-admin migrate - settings = mysite.settings_env
Понимание приложений Django
В Django есть довольно запутанное различие между проектом и приложениями. Большинство руководств расскажут вам, что каждое приложение django является функцией вашего приложения. Это привело к тому, что я сделал отдельное приложение django для пользователей, сообщений и комментариев. Я просто создавал приложение для каждой модели, которое добавляет ненужной сложности и делает ваш проект неэффективным. Приложение относится к подмодулю проекта. Он самодостаточен и не связан с другими приложениями в проекте, так что теоретически вы можете взять его и поместить в другой проект без каких-либо изменений. Мы хотим, чтобы каждое сообщение принадлежало пользователю, а каждый комментарий - сообщению; они принадлежат одному приложению. Вы можете думать об этом как об автономном модуле Python. В простом проекте может быть только одно приложение.
Специализация вида администратора
Одна из самых мощных частей Django - это автоматический интерфейс администратора. Он считывает метаданные из ваших моделей, чтобы обеспечить быстрый, ориентированный на модели интерфейс, где доверенные пользователи могут управлять контентом на вашем сайте. Базовые настройки административного представления позволят вам увидеть все модели вашего приложения и экземпляры этих моделей, то есть всех ваших пользователей и их сообщения. Специализация на этом может дать администратору ваших приложений лучший обзор данных приложений.
Более подробную информацию о встроенных строках Django вы можете найти здесь. Встроенные Django позволяют просматривать модель и связанные с ней модели. В приведенном выше примере встроенные файлы позволяют администраторам просматривать сообщение и некоторые комментарии к нему. Это мощный инструмент для модерации. Поля read_only помогают убедиться, что пользователи-администраторы случайно не изменят важную информацию. Если вы специализируете свою пользовательскую модель, настройка fieldsets позволяет вам добавлять поля в ваших специализированных пользователей. Поля поиска позволяют фильтровать, какие поля будут использоваться в поиске администратора, что делает ваш поиск более точным.
Перейти к представлениям на основе класса
Раньше меня очень пугали представления на основе классов (CBV), но как только я переключился с представлений на основе методов (MBV), я стал более счастливым человеком. CBV довольно просты, что делает их волшебными. Здесь так мало кода, что сначала кажется, что он не имеет смысла. Если вы хотите сделать простой вид для перечисления всех сообщений в вашем приложении, упорядоченных по последнему сообщению:
CBV является подклассом generic.ListView, поэтому вам не нужно создавать набор запросов (models.Post.objects.all), вместо этого вы просто указываете модель и свойство упорядочивания. Вам также не нужно указывать шаблон, общие представления будут искать шаблон post_list в шаблонах вашего приложения. В ваших шаблонах у вас будут сообщения из набора запросов, которые представляют собой список всех сообщений в вашем приложении, упорядоченных по самому последнему сообщению.
CBV также позволяют делать более мощные вещи, такие как get_context_data и dispatch. Я расскажу об этом во второй части этой серии.
Добавление форм в views.py
Рекомендуется помещать все формы в отдельный файл forms.py, но поскольку формы - это всего лишь способ форматирования представления, имеет смысл размещать каждую форму вверху представления. Вы будете работать над представлением и формой одновременно, и если ваш models.py станет слишком заполненным, вы можете переместить некоторые из ваших моделей во второй файл модели. Правильно, ваши модели не обязательно должны быть в одном файле.
Эта настройка позволяет одновременно работать как с формой, так и с представлением.
Написание тщательных тестов
Раньше моей наименее любимой частью кодирования было написание тестов. Я все еще не люблю писать модульные тесты, но я определенно ценю их. У тестов есть способ замедлить наплыв кода, но это хорошо, потому что вы не хотите тратить часы на программирование только для того, чтобы понять, что на самом деле вы добавляете больше ошибок, чем функций. Хороший способ освоить тесты - это разработать какой-то шаблон, которому вы можете следовать. Конечно, каждая функция индивидуальна, и некоторые из них требуют более тщательного изучения, чем другие, но хороший способ построить здоровые отношения с тестами - это разработать согласованный шаблон или подход.
A. Разделите тесты по имени файла, т.е. поместите все тесты для views.py в test_views.py
B. Сначала протестируйте свои модели: модели намного проще тестировать, и они дают вам хорошую отправную точку. Хороший тест для вашей модели поста.
C. Проверьте свои настройки: ну, вы же не хотите, чтобы люди «случайно» испортили ваш файл настроек. Если у вас более одного файла настроек, вы можете создать отдельный тестовый файл для каждого из них:
Этот тест получает настройки в вашем файле settings_base, а затем сравнивает их с настройками, которые вы ожидаете получить. Обязательно обновляйте expected_settings всякий раз, когда изменяются ваши настройки.
D. Тестовые представления. Хорошим шаблоном для просмотра тестов является шаблон: test_get__authenticated, test_get__authenticated, test_post__empty, test_not_found, test_post__unauthenticated, test_post__sucessful. Я считаю, что эти варианты использования - хорошее начало. После написания нескольких простых тестов для представления становится проще выполнять более сложные тесты.
Лучше простое, чем сложное.
Он - мои любимые учителя Django, у него есть учебники, которые проведут вас через Django от начала до развертывания.
Спасибо, что читаете мой блог, скоро выйдет вторая часть этой серии. Огромное спасибо Pi Delport и Kaitlyn Crawford за то, что научили меня буквально всему, что я знаю о Django. И, конечно же, замечательные люди, пишущие документацию по Django.
