Плюсы и минусы django

Что такое Django

Последнее обновление: 14.02.2018

Django — это фреймворк для создания веб-приложений с помощью языка программирования Python.


Django был создан в 2005 году, когда веб-разработчики из газеты Lawrence Journal-World стали использовать Python в качестве языка для создания веб-сайтов. А в 2008 году вышел публичный первый релиз фреймворка. На сегодняшний день он продолжает развиваться. Так, текущей версией фреймворка на момент написания этой статьи является версия 2.0, которая вышла 3 декабря 2017 года. Ну и также постоянно выходят подверсии.

Django довольно популярен. Он используется на многих сайтах, в том числе таких, как Pinterest, PBS, Instagram, BitBucket, Washington Times, Mozilla и многих других.

Фреймворк Django реализует архитектурный паттерн Model-View-Template или сокращенно MVT, который по факту является модификацией распростаненного в веб-программировании паттерна MVC (Model=-View-Controller).

Схематично мы можем представить архитектуру MVT в Django следующим образом:

Основные элементы паттерна:

  • URL dispatcher: при получение запроса на основании запрошенного адреса URL определяет, какой ресурс должен обрабатывать данный запрос.

  • View: получает запрос, обрабатывает его и отправляет в ответ пользователю некоторый ответ. Если для обработки запроса необходимо обращение к модели и базе данных, то View взаимодействует с ними. Для создания ответа может применять Template или шаблоны. В архитектуре MVC этому компоненту соответствуют контроллеры (но не представления).

  • Model: описывает данные, используемые в приложении. Отдельные классы, как правило, соответствуют таблицам в базе данных.

  • Template: представляет логику представления в виде сгенерированной разметки html. В MVC этому компоненту соответствует View, то есть представления.

Когда к приложению приходит запрос, то URL dispatcher определяет, с каким ресурсом сопоставляется данный запрос и передает этот запрос выбранному ресурсу. Ресурс фактически представляет функцию или View, который получает запрос и определенным образом обрабатывает его. В процессе обработки View может обращаться к моделям и базе данных, получать из нее данные, или, наоборот, сохранять в нее данные. Результат обработки запроса отправляется обратно, и этот результат пользователь видит в своем браузере. Как правило, результат обработки запроса представляет сгенерированный html-код, для генерации которого применяются шаблоны (Template).

Вперед

Дополнительные файлы Django-приложения

Перед размещением кода на Heroku, нам понадобится сделать четыре изменения в нашем проекте Pages:

  • обновить ;
  • создать новый файл ;
  • установить на нашем веб-сервере ;
  • изменить строчку в файле .

Внутри уже существующего файла уточним используемую версию Python — в нашем случае 3.8. Для этого добавим в нижней части файла следующие две строчки.

Pipfile

Python

python_version = «3.8»

1 2

requires

python_version=»3.8″

Далее запускаем для генерации подходящего .

Shell

(pages) $ pipenv lock

1 (pages)$pipenv lock

В действительности, в поисках информации о виртуальном окружении, Heroku заглядывает внутрь нашего Pipfile.lock. По этой причине здесь нам пришлось добавить настройку версии языка программирования.

Затем создаем , который является специфическим файлом конфигурации для Heroku.

Shell

(pages) $ touch Procfile

1 (pages)$touchProcfile

Откройте при помощи текстового редактора и добавьте следующее:

Python

web: gunicorn pages_project.wsgi —log-file —

1 webgunicorn pages_project.wsgi—log-file-

Это говорит о том, что нам надо использовать Gunicorn, что является сервером, подходящем для продакшена, в то время как собственный сервер Django работает только в локальном окружении. Устанавливаем gunicorn при помощи Pipenv.

Shell

(pages) $ pipenv install gunicorn==19.9.0

1 (pages)$pipenv install gunicorn==19.9.0

Конфигурация для веб-сервера находится в файле wsgi.py, который Django автоматически создает для каждого нового проекта. Он находится в основной папке нашего проекта. Поскольку наш проект называется , сам файл находится в .

Последний шаг — небольшое изменение в файле . Прокрутите вниз до части и добавьте . Результат должен получиться следующим:

Python

# pages_project/settings.py ALLOWED_HOSTS =

1 2

# pages_project/settings.py

ALLOWED_HOSTS=’*’

Однако мы использовали знак звездочки , а это значит, что все домены являются приемлемыми. На сайте продакшн-уровня вместо этого вам пришлось бы составить ясный список допустимых доменов.

Для проверки изменений мы выполним команду , добавляем новые файлы и затем коммитим их:

Shell

(pages) $ git status (pages) $ git add -A (pages) $ git commit -m «New updates for Heroku deployment»

1 2 3

(pages)$git status

(pages)$git add-A

(pages)$git commit-m»New updates for Heroku deployment»

Теперь мы можем разместить код на GitHub, создав онлайн копию наших изменений в коде.

Shell

(pages) $ git push -u origin master

1 (pages)$git push-uorigin master

Запускаем сайт на Django через Heroku

Можете бесплатно зарегистрироваться на сайте Heroku. После подтверждения электронной почты вы будете перенаправлены на главную страницу.

Главная страница Heroku


Теперь необходимо установить Heroku Command Line Interface (CLI), необходимый для работы с командной строкой. Нам нужно установить Heroku глабально — таким образом он будет. Откройте новую вкладку командной строки при помощи комбинации , которая подходит как для Mac, так и для Windows.

Работая на Mac, в новой вкладке при помощи Homebrew установите Heroku:

Shell

$ brew install heroku/brew/heroku

1 $brew install herokubrewheroku

Пользователям Windows нужно выбрать 32-битную или 64-битную версию установщика на странице загрузки . Для пользователей Linux на сайте Heroku предусмотрены специальные инструкции для установки.

Установка Heroku на Ubuntu

Shell

sudo snap install —classic heroku

1 sudo snap install—classic heroku

После завершения установки можете закрыть используемую вкладку и вернуться к главной вкладке с активным виртуальным окружением .

Наберите команду , после чего используйте только что установленные адрес электронной почты и пароль для Heroku.

1 2 3 4 5

(pages)$heroku login

Enter your Heroku credentials

Emailwill@wsvincent.com

Password*********************************

Logged inaswill@wsvincent.com

Установка Django через pipenv

Для того чтобы оценить в действии, создадим новую директорию и установим Django. Первым делом переместимся на рабочий стол Desktop. Там будет создана новая директория , куда нам нужно будет попасть при помощи команды .

Shell

$ cd ~/Desktop $ mkdir django $ cd django

1 2 3

$cd~Desktop

$mkdirdjango

$cddjango

Теперь используем Pipenv для инсталляции Django.

Shell

$ pipenv install django==3.0

1 $pipenv install django==3.0

Если загляните внутрь нашей папки, то увидите, что в ней появилось два новых файла: и . Теперь у нас есть вся информация, необходимая для создания нового виртуального окружения, однако пока ничего не активировано. Исправим положение через .

Shell

$ pipenv shell

1 $pipenv shell

При работе на Ubuntu вы увидите, что название текущей директории в командной строке взято в скобки. Это значит, что виртуальное окружение активировано. Будучи внутри папки , перед знаком командной строки мы увидим .

Стоит иметь в виду, что из-за в системе Windows, сейчас нет возможности получить визуальное подтверждение об активации виртуального окружения. Однако в следующей секции можно запустить — тогда станет ясно, что виртуальное окружение Django установлено должным образом.

Shell

(django) $

1 (django)$

Все работает! Теперь создаем новый проект Django под названием при помощи следующей команды. Не забудьте в конце поставить точку.

Shell

(django) $ django-admin startproject test_project .

1 (django)$django-admin startproject test_project.

Немного остановимся на причине использования точки (.) в предыдущей команде. Если вы просто запустите то Django по умолчанию создаст следующую структуру:

Структура

Shell

└── test_project ├── manage.py └── test_project ├── __init__.py ├── settings.py ├── urls.py └── wsgi.py

1 2 3 4 5 6 7

└──test_project

├──manage.py

└──test_project

├──__init__.py

├──settings.py

├──urls.py

└──wsgi.py

Как видите, создается новая директория , в ней файл и еще одна директория . Чувствуется повторение, ведь ранее мы уже создали директорию на рабочем столе и переместились в нее. Будет лучше выполнить команду с точкой на конце. Это нужно для установки в данную конкретную папку — на сей раз результат будет таков:

Структура 

Shell

├── manage.py └── test_project ├── __init__.py ├── settings.py ├── urls.py └── wsgi.py

1 2 3 4 5 6

├──manage.py

└──test_project

├──__init__.py

├──settings.py

├──urls.py

└──wsgi.py


Стоит отметить, что по сути особого значения не имеет, будет ли на конце команды точка или нет, однако но некоторые разработчики предпочитают ее включать.

Осталось убедиться, что все работает. Для этого запустим локальный веб-сервер Django.

Shell

(django) $ python manage.py runserver

1 (django)$python manage.pyrunserver

Мы получим такой ответ:

Shell

Watching for file changes with StatReloader Performing system checks…

System check identified no issues (0 silenced).

You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions. Run ‘python manage.py migrate’ to apply them.

May 05, 2020 — 12:36:09 Django version 3.0, using settings ‘test_project.settings’ Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.

1 2 3 4 5 6 7 8 9 10 11 12

Watching forfilechanges with StatReloader

Performing system checks…

System check identified no issues(silenced).

You have17unapplied migration(s).Your project may notwork properly untilyou apply the migrations forapp(s)admin,auth,contenttypes,sessions.

Run’python manage.py migrate’toapply them.

May05,2020-123609

Django version3.0,using settings’test_project.settings’

Starting development server athttp127.0.0.18000

Quit the server with CONTROL-C.

При посещении откроется следующая страница:

Приветственная страница Django

Для остановки локального сервера используйте комбинацию . После этого выйти из виртуального окружения можно при помощи команды .

Shell

(django) $ exit

1 (django)$exit

Вновь активировать виртуальное окружение можно в любое время. — для этого используется команда в терминале.

Если вы сталкиваетесь с виртуальными окружениями впервые, сейчас они могут показаться немного запутанными, но не беспокойтесь — по ходу изучения все прояснится. Базовый принцип строится на установке новых пакетов через , их активации с и выхода через по мере завершения процесса.

Будет не лишним отметить, что через командную строку за раз можно активировать только одно виртуальное окружение. Мы будем создавать новое виртуальное окружение для каждого проекта. По этой причине перед созданием нового проекта не забывайте выходить из текущего окружения через или открывайте другие вкладки для новых проектов.

У Django прекрасная документация

Django даже на свет появился с документацией, значительно превосходящей по качеству обычный стандарт open-source проектов, а со временем его документация стала еще лучше.

При первом выходе «в люди» документация была одной из «изюминок» Django, чем-то, что выделяло его на общем фоне. Большинство фреймворков того времени имели разве что алфавитный указатель модулей, методов и атрибутов. Такую документацию хорошо использовать в качестве справочника, но она практически бесполезна, когда вы делаете свои первые шаги в использовании программы.

Сегодня документация Django уже не столь уникальна в плане качества, но она по-прежнему может служить одним из лучших образцов документирования проектов с открытым исходным кодом. И разработчики постоянно заботятся о ее поддержке.

License

Copyright 2011-present, Encode OSS Ltd. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

  • Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS «AS IS» AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Классовые представления в Django

Ранние версии Django поддерживали только функциональные представления (они же представления на основе функции), однако разработчики довольно быстро поняли, что им приходится повторять из раза в раз один и тот же паттерн. Писать представление, которое составляет всех объектов в модели. Писать представление, которое показывает только один детализированный элемент модели. И так далее.

Функциональные представления-генерики были введены для того чтобы избавить разработчиков от этих монотонных паттернов. Однако расширить возможности имеющихся представлений или изменить их должным образом оказалось не так уж просто. В результате в Django появились классовые представления-генерики, которые были легкими в использовании и давали возможность приспосабливать имеющиеся представления под нужны наиболее часто встречающихся случаев.

Классы являются фундаментальной частью Python. В нашем представлении для отображения шаблона мы используем встроенный . Обновим файл .

Python

# pages/views.py from django.views.generic import TemplateView

class HomePageView(TemplateView): template_name = ‘home.html’

1 2 3 4 5 6

# pages/views.py

fromdjango.views.generic importTemplateView

classHomePageView(TemplateView)

template_name=’home.html’

Creating the Polls app¶

Now that your environment – a “project” – is set up, you’re set to start doing work.

Each application you write in Django consists of a Python package that follows a certain convention. Django comes with a utility that automatically generates the basic directory structure of an app, so you can focus on writing code rather than creating directories.

Projects vs. apps

What’s the difference between a project and an app? An app is a Web application that does something – e.g., a Weblog system, a database of public records or a small poll app. A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.

Your apps can live anywhere on your . In this tutorial, we’ll create our poll app in the same directory as your file so that it can be imported as its own top-level module, rather than a submodule of .

To create your app, make sure you’re in the same directory as and type this command:

/ 

That’ll create a directory , which is laid out like this:

polls
    __init__.py
    admin.py
    apps.py
    migrations
        __init__.py
    models.py
    tests.py
    views.py

The development server¶

Let’s verify your Django project works. Change into the outer directory, if you haven’t already, and run the following commands:

/ 

You’ll see the following output on the command line:

Performing system checks...

System check identified no issues (0 silenced).

You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.

August 21, 2020 - 15:50:53
Django version 3.1, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Note

Ignore the warning about unapplied database migrations for now; we’ll deal with the database shortly.

You’ve started the Django development server, a lightweight Web server written purely in Python. We’ve included this with Django so you can develop things rapidly, without having to deal with configuring a production server – such as Apache – until you’re ready for production.

Now’s a good time to note: don’t use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making Web frameworks, not Web servers.)

Now that the server’s running, visit http://127.0.0.1:8000/ with your Web browser. You’ll see a “Congratulations!” page, with a rocket taking off. It worked!

Changing the port

By default, the command starts the development server on the internal IP at port 8000.

If you want to change the server’s port, pass it as a command-line argument. For instance, this command starts the server on port 8080:


/ 

If you want to change the server’s IP, pass it along with the port. For example, to listen on all available public IPs (which is useful if you are running Vagrant or want to show off your work on other computers on the network), use:

/ 

is a shortcut for 0.0.0.0. Full docs for the development server can be found in the reference.

Среда разработки веб приложений на Python

Сервер разработки

Django и Flask содержат сервера разработки, которые делают процесс создания веб приложения более удобным и быстрым. Они содержат функции, которые принято ожидать от взрослого веб-фреймворка, такие как возможность обработки запросов, подача статических файлов (для разработки), и обнаружить изменения в вашем коде для автоматического перезапуска, чтобы ваши изменения вступили в силу.

Утилиты командной строки

Django предоставляет утилиту командной строки, которая доступна с рядом административных команд. Одна из них запускает сервер разработки, в то время как другие используются для управления файлами статики и миграциями. Сторонние приложения могут улучшить утилиту командной строки, предоставляя собственные команды управления, кроме этого, может полезным (и легким) внесение ваших собственных команд.

Python

python manage.py

1 python manage.py

Результат:

Shell

Доступные команды:

changepassword createsuperuser

remove_stale_contenttypes

clearsessions

collectstatic findstatic runserver

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

Доступныекоманды

auth

changepassword

createsuperuser

contenttypes

remove_stale_contenttypes  

django

check

compilemessages

createcachetable

dbshell

diffsettings

dumpdata

flush

inspectdb

loaddata

makemessages

makemigrations

migrate

sendtestemail

shell

showmigrations

sqlflush

sqlmigrate

sqlsequencereset

squashmigrations

startapp

startproject

test

testserver

sessions

clearsessions

staticfiles

collectstatic

findstatic

runserver

Flask также предоставляет собственную встроенную утилиту командной строки, которая использует модуль click, что является признаком взрослого и солидного набора инструментов интерфейса командной строки. Также как и в Django, вы можете создать собственные пользовательские команды, а расширения Flask также могут внести свой вклад.

Тестирование

Оба фреймворка предлагают инструменты, основанные на встроенной платформе Python Unittest, чтобы упростить тестирование вашего веб-приложения. Каждый из них располагает тест клиентом, который позволяет вам легко отправлять тестовые запросы в конечные точки и проверять ответ для программной проверки правильности поведения.

Так как и Flask и Django используют Python Unittest, вы можете поменять доступные по умолчанию тестовые раннеры и настроить тесты на свое усмотрение.

Пишем тесты для Django приложений

Наконец-то мы добрались до тестов

Хотя в приложениях это является базовым концептом, очень важно, чтобы добавление тестов в Django вошло у вас в привычку. Цитируя Джейкоба Каплан-Мосса, одного из создателей Django: «Непротестированный код можно считать сломанным«

Написание тестов важно, так как это автоматизирует процесс подтверждения того, что код работает должным образом. В приложении, подобном этому, вы сами можете увидеть, что домашняя страница и страница с описанием проекта на месте и содержат все необходимые данные

Однако с ростом нашего проекта, будет увеличиваться и количество веб-страниц, поэтому идея самостоятельной проверки сотен или даже тысяч страниц не представляется возможной.

Кроме того, когда мы делаем определенные изменения в коде — добавляем новый функционал, изменяем существующий, удаляем неиспользуемые элементы сайта — мы должны быть уверены в том, что все оставшиеся аспекты сайта по-прежнему работают должным образом. Автоматические тесты действуют таким образом, что компьютер каждый раз будет проверять работоспособность проекта, отталкиваясь от единожды написанного ранее правильного кода. К счастью, в Django есть встроенные инструменты для написания и запуска тестов.

Python

# pages/tests.py from django.test import SimpleTestCase

class SimpleTests(SimpleTestCase): def test_home_page_status_code(self): response = self.client.get(‘/’) self.assertEqual(response.status_code, 200)

def test_about_page_status_code(self): response = self.client.get(‘/about/’) self.assertEqual(response.status_code, 200)

1 2 3 4 5 6 7 8 9 10 11 12

# pages/tests.py

fromdjango.testimportSimpleTestCase

classSimpleTests(SimpleTestCase)

deftest_home_page_status_code(self)

response=self.client.get(‘/’)

self.assertEqual(response.status_code,200)

deftest_about_page_status_code(self)

response=self.client.get(‘/about/’)

self.assertEqual(response.status_code,200)

База данных нам пока не нужна, поэтому сейчас можно использовать простой . При наличии базы данных нужно обратиться к . Затем проводится проверка, в результате которой у каждой страницы должен быть код состояния 200 — это успешный ответ на стандартный HTTP запрос. Таким образом, становится понятно, что запрашиваемая страница действительно существует, но при этом не раскрывается ее содержимое.

Для запуска теста остановите веб-сервер, использовав комбинацию , а затем наберите в командной строке :

Shell

(pages) $ python manage.py test Creating test database for alias ‘default’… System check identified no issues (0 silenced). .. ———————————————————————- Ran 2 tests in 0.014s

OK Destroying test database for alias ‘default’…

1 2 3 4 5 6 7 8 9

(pages)$python manage.pytest

Creating testdatabase foralias’default’…

System check identified no issues(silenced).

..

———————————————————————-

Ran2tests in0.014s

  OK

Destroying testdatabase foralias’default’…

Все успешно! В будущем мы будем использовать более сложные тесты, особенно это важно при работе с базами данных

Различия между версиями¶

The text documentation in the master branch of the Git repository contains the «latest and greatest» changes and additions. These changes include documentation of new features targeted for Django’s next . For that reason, it’s worth pointing out our policy to highlight recent changes and additions to Django.

Мы следуем следующей политике:

  • The development documentation at https://docs.djangoproject.com/en/dev/ is from the master branch. These docs correspond to the latest feature release, plus whatever features have been added/changed in the framework since then.
  • As we add features to Django’s development version, we update the documentation in the same Git commit transaction.
  • To distinguish feature changes/additions in the docs, we use the phrase: «New in Django Development version» for the version of Django that hasn’t been released yet, or «New in version X.Y» for released versions.
  • Documentation fixes and improvements may be backported to the last release branch, at the discretion of the committer, however, once a version of Django is , that version of the docs won’t get any further updates.
  • The main documentation Web page includes links to documentation for previous versions. Be sure you are using the version of the docs corresponding to the version of Django you are using!

Разница между Flask и Django

Flask и Django — оба взрослые, расширяемые веб фреймворка, которые, в корне своем, предоставляют аналогичный функционал в обработке запросов, поддержке документов, но различаются в масштабе ответственности.

Большая часть отличий между двумя фреймворками проистекают из разных подходов, остальные — из отличных основных проектных решений. Вот небольшой список ключевых различий, которые могут повлиять на ваше решение:

  • Объект Request — Flask использует локальные потоки, а Django передает запрос там, где это нужно.
  • Формы — Django доступен со встроенными формами, которые интегрируются с ORM и админкой сайта. Flask не поддерживает формы по умолчанию, но вы можете использовать WTForms, чтобы заполнить этот пробел.
  • Базы данных — Django доступен со встроенной ORM и системой миграции, которая может управлять базами данных. Flask не может этим похвастаться, однако есть инструменты, такие как SQLAlchemy, которые предоставляют аналогичный функционал (или даже больше).
  • Аутентификация и привилегии пользователям — Django предоставляет приложение аутентификации, которое предоставляет реализацию по умолчанию для пользовательского управления и привилегий. Flask предоставляет безопасные куки в качестве инструмента вашей собственной реализации.
  • Панель администратора — Django включает в себя полностью интегрированный админ-интерфейс для управления данными приложения. Flask не имеет таких функций, но Flask-Admin — очень популярное расширение, которое можно использовать для создания аналогичного административного инструмента.

С этим читают