Что такое django и почему он столь популярен?

Установка 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 в созданное
виртуальное окружение. Так как я в своей работе использую интегрированную среду
PyCharm, то дальнейшие
действия по работе с виртуальным окружением буду делать через нее. Уверен, что
большинство из вас тоже пользуются PyCharm, поэтому все
должно быть предельно понятно. Итак, открываем созданный проект, указав папку:

D:/Python/django/djsite

и после
индексирования всех файлов интегрированная среда автоматически активизирует
установленное виртуальное окружение. Если это по каким-то причинам не
произошло, то нужно вручную указать PyCharm это окружение.
Для
этого следует перейти на вкладку Project Interpreter:

File
-> Settings -> Project:djsite -> Project Interpreter

и указать
интерпретатор из установленного окружения.

Далее, находясь
в корневой папке проекта, мы должны выполнить непосредственно установку Django с помощью
очевидной команды:

pip install
django

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

pip list

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

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

django-admin

Так вот, для
создания нашего первого сайта, нам понадобится команда startproject, которая
записывается так:

django-admin
startproject <имя сайта>

Здесь «имя
сайта», обычно, является доменным именем. Например, если мы собираемся
располагать сайт на домене:

coolsite.ru

то в качестве
имени логично выбрать coolsite. Давайте так и сделаем, выполним команду:

django-admin
startproject coolsite

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

cd coolsite

и выполним файл manage.py с командой runserver:

python manage.py
runserver

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

Ctrl + Break (а также Ctrl + C в Windows)

а, затем, снова
запустить:

python manage.py
runserver

Также обратите
внимание, что при первом запуске сервера в проекте появился еще один файл db.sqlite3 – файл БД SQLite3. Дело в том,
что по умолчанию Django использует именно такую СУБД

В
дальнейшем, мы можем это изменить и указать любую другую СУБД, которую
поддерживает данный фреймворк. Это может быть:

PostgreSQL, MariaDB, MySQL, Oracle и SQLite

Но вернемся к
запуску сервера. Его можно запускать также и со следующими параметрами:

python
manage.py runserver 4000

или так:

python manage.py runserver
192.168.1.1:4000

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

Видео по теме

#1. Django — что это такое, порядок установки

#2. Модель MTV. Маршрутизация. Функции представления

#3. Маршрутизация, обработка исключений запросов, перенаправления

#4. Определение моделей. Миграции: создание и выполнение

#5. CRUD — основы ORM по работе с моделями

#6. Шаблоны (templates). Начало

#7. Подключение статических файлов. Фильтры шаблонов

#8. Формирование URL-адресов в шаблонах

#9. Создание связей между моделями через класс ForeignKey

#10. Начинаем работу с админ-панелью

#11. Пользовательские теги шаблонов

#12. Добавляем слаги (slug) к URL-адресам

#13. Использование форм, не связанных с моделями

#14. Формы, связанные с моделями. Пользовательские валидаторы

#15. Классы представлений: ListView, DetailView, CreateView

#16. Основы ORM Django за час

#17. Mixins — убираем дублирование кода

#18. Постраничная навигация (пагинация)

#19. Регистрация пользователей на сайте

#20. Делаем авторизацию пользователей на сайте

#21. Оптимизация сайта с Django Debug Toolbar

#22. Включаем кэширование данных

#23. Использование капчи captcha

#24. Тонкая настройка админ панели

Supported Versions

Feature releases (A.B, A.B+1, etc.) will happen roughly every eight months.
These releases will contain new features, improvements to existing features, and such.

Patch releases (A.B.C, etc.) will be issued as needed, to
fix bugs and/or security issues. These releases will be 100% compatible with
the associated feature release, unless this is impossible for security
reasons or to prevent data loss. So the answer to «should I upgrade to the
latest patch release?” will always be «yes.»

Certain feature releases will be designated as long-term support
(LTS) releases. These releases will get security and data loss
fixes applied for a guaranteed period of time, typically three years.

See the for detailed guidelines about what fixes will be backported.

Release Series	Latest Release	End of mainstream support	End of extended support
3.2 LTS	3.2	December 2021	April 2024
3.1	3.1.8	April 6, 2021	December 2021
2.2 LTS	2.2.20	December 2, 2019	April 2022

Конвертеры маршрутов в Django 2.0+ (path converters)

Всем привет!
Маршрутизация в Django со второй версии фреймворка получила замечательный инструмент — конвертеры. С добавлением этого инструмента появилась возможность не только гибко настраивать параметры в маршрутах, но и разделять зоны ответственности компонентов.
Меня зовут Александр Иванов, я наставник в Яндекс.Практикуме на факультете бэкенд-разработки и ведущий разработчик в Лаборатории компьютерного моделирования. В этой статье я расскажу о конвертерах маршрутов в Django и покажу преимущества их использования.
Первое, с чего начну, — границы применимости:

1. версия Django 2.0+;
2. регистрация маршрутов должна выполняться с помощью .

Итак, когда к Django-серверу прилетает запрос, он сперва проходит через цепочку middleware, а затем в работу включается URLResolver (). Задача последнего — найти в списке зарегистрированных маршрутов подходящий.
Для предметного разбора предлагаю рассмотреть следующую ситуацию: есть несколько эндпоинтов, которые должны формировать разные отчёты за определённую дату. Предположим, что эндпоинты выглядят так:

Перейдем к практике

Выделим в Django приложениях несколько слоев, которые есть в каждом туториале и почти в каждом проекте:

• front-end/templates

• serializers/forms

• views

• models

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

Первый кейс — создание заказа.  При создании заказа нам нужно:

• проверить валидность заказа и доступность товаров

• создать заказ

• зарезервировать товар на складе

• передать заявку менеджеру

• оповестить пользователя о том, что его заказ принят в работу

Второй кейс — просмотр списка моих заказов. Здесь все просто, мы должны показать пользователю список его заказов:

получить список заказов пользователя 

Хекслет

В рамках курса вы познакомитесь с Django, самым известным full-stack Web-фреймворком для Python. Курс поведает о том, что же такое «full stack Web-фреймворки», что за мощь скрывается за Django и почему он так популярен.

Уроки курса:

• Введение
  Познакомиться с курсом и взглянуть на предмет обсуждения — фреймворк Django — с высоты птичьего полёта.
• Почему Django
  Узнать, чем же конкретно хорош Django и что заставляет множество разработчиков выбирать именно этот фреймворк.
• Быстрый старт с Django
  Создать простейшее Web-приложение на Django, научиться запускать в режиме разработки и в боевых условиях.
  теория
• Приложения
  Познакомиться главным средством организации кода в больших проектах — с приложениями.
  теория
• Представления (Views)
  Поглубже познакомиться с представлениями-функциями и узнать о представлениях-классах.
  теория

Размещение Django сайта на Heroku

Последний шаг — это фактическое размещение кода на Heroku. Если вы раньше настраивали сервер, вы будете поражены тем, как сильно Heroku упрощает данный процесс.

Весь процесс будет состоять из следующих этапов:

• создайте новое приложение на Heroku и вставьте в него наш код;
• настройте взаимодействие с git, то есть так называемый «hook» для Heroku;
• настройте приложение на игнорирование статических файлов;
• для активации приложения в онлайн режим, запустите сервер Heroku;
• посетите приложение, перейдя по предоставленному Heroku URL адресу.

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

Shell

(pages) $ heroku create
Creating app… done, ⬢ fathomless-hamlet-26076
https://fathomless-hamlet-26076.herokuapp.com/ |
https://git.heroku.com/fathomless-hamlet-26076.git

1 2 3 4

(pages)$heroku create Creating app…done,⬢fathomless-hamlet-26076 httpsfathomless-hamlet-26076.herokuapp.com| httpsgit.heroku.comfathomless-hamlet-26076.git

На данный момент нам остается только настроить Heroku. Для этого укажем Heroku проигнорировать статические файлы вроде CSS и JavaScript, которые Django по умолчанию попытается исправить под себя. Выполним следующую команду:

Shell

(pages) $ heroku config:set DISABLE_COLLECTSTATIC=1

1	(pages)$heroku configset DISABLE_COLLECTSTATIC=1

Теперь можем разместить код на Heroku.

Shell

(pages) $ git push heroku master

1	(pages)$git push heroku master

Если бы мы только что набрали , то код был бы загружен в GitHub, а не в Heroku. Добавление слова в команду позволяет отправить код на Heroku. Первые несколько раз это может сбивать с толку.

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

Введите следующую команду.

Shell

(pages) $ heroku ps:scale web=1

1	(pages)$heroku psscale web=1

Все готово! Последним шагом станет подтверждение того, что наше приложение действительно запущено и работает в режиме онлайн. Если вы выполните команду , ваш браузер откроет новую вкладку с URL адресом вашего приложения:

Shell

(pages) $ heroku open

1	(pages)$heroku open

Наш адрес . Вы можете убедиться в этом, вот появившаяся домашняя страница:

Домашняя страница на Heroku

Страница «About» также открылась должным образом:

Страница «About» на Heroku

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

3.5. Определяем URL’ы

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

Обратите внимание на замыкающий символ ; как думаете, почему он важен?
вторым параметром указывается вызываемое представление. Это может быть как непосредственно вызываемый объект (импортированный вручную), так и строка описывающая его

Если это строка, то в случае соответствия URL-шаблона строке запроса, Django сам импортирует необходимый модуль (до последней точки), и вызовет последний сегмент строки (после последней точки);
замете, что когда мы используем представление-класс, мы обязаны использовать реальный объект, а не строку описывающую этот объект. Мы должны так делать из за того, что мы вызываем метод класса . Этот метод возвращает обертку над нашим классом, которую может вызвать диспетчер URL Django;
имя, данное URL-шаблону, позволят вам делать обратный поиск;
имя URL полезно, когда вы ссылаетесь из одного представления на другое, или выполняете перенаправление, так как вы можете управлять структурой URL’ов из одного места.

переменных

Установка и настройка среды разработки Python/Django

На этом этапе мы видим перед собой приветственное окно приложения с предложением создать новый проект, открыть существующий или же импортировать из системы контроля версий. Нас же пока интересует первый пункт – Create New Project. Нажимаем его и переходим в созданию нового проекта.

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

Вторая строчка Interpreter отвечает за выбор установленного в системе интерпретатора языка Python. Их может быть несколько, но пока мы не будем вдаваться в нюансы. Сразу отмечу, что для каждого проекта лучше создавать отдельную виртуальную среду (VirtualEnv), которая будет содержать установленные модули, необходимые для конкретного проекта и их настройки и версии не будут влиять на другие проекты. Давайте создадим новую VirtualEnv нажав на шестеренке справа и выбрав пункт Create VirtualEnv.

Для VirtualEnv так же необходимо задать имя, выбрать расположение в файловой системе и версию интерпретатора Python, которая будет использоваться. Я предпочитаю виртуальной среде давать имена аналогичные проекту, чтобы так же легко можно было разобраться для какого проекта она была создана.

Нажимаем ОК и ждем пока закончится процесс создания виртуальной среды. После нажимаем на кнопку Create внизу справа и запускаем процесс создания проекта.

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

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

Активация моделей¶

Эта небольшая часть кода моделей предоставляет Django большое количество информации, которая позволяет Django:

• Создать структуру базы данных (CREATE TABLE) для приложения.

• Создать Python API для доступа к данным объектов Poll и Choice.

Но первым делом мы должны указать нашему проекту, что приложение polls установлено.

Philosophy

Приложения Django “подключаемые”: вы можете использовать приложение в нескольких проектах и вы можете распространять приложение, так как они не связаны с конкретным проектом Django.

Отредактируйте файл settings.py и измените настройку добавив строку 'polls'. В результате получим:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
    'polls',
)

Теперь Django знает что необходимо использовать приложение polls. Давайте выполним следующую команду:

python manage.py sql polls

Вы увидите приблизительно такое (SQL запросы CREATE TABLE для приложения голосования):

BEGIN;
CREATE TABLE "polls_poll" (
    "id" serial NOT NULL PRIMARY KEY,
    "question" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED,
    "choice" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
COMMIT;

Обратите внимание на следующее:

• Полученные запросы зависят от базы данных, которую вы используете.

• Названия таблиц созданы автоматически из названия приложения(polls) и названия модели в нижнем регистре – poll и choice. (Вы можете переопределить это.)

• Первичные ключи (ID) добавлены автоматически. (Вы можете переопределить и это.)

• Django добавляет "_id" к названию внешнего ключа. (Да, вы можете переопределить и это.)

• Внешний ключа определяется явно через REFERENCES.

• Учитываются особенности базы данных, которую вы используете. Специфические типы данных такие как auto_increment (MySQL), serial (PostgreSQL), или integer primary key (SQLite) будут использоваться автоматически. То же касается и экранирование называний, что позволяет использовать в названии кавычки – например, использование одинарных или двойных кавычек. Автор этого урока использует PostgreSQL, так что примеры используют синтаксис PostgreSQL.

• Команда не выполняет SQL запросы в базе данных — она просто выводит их на экран, чтобы вы могли увидеть какой SQL создает Django. Если вы хотите, можете скопировать и выполнить этот SQL в консоли вашей базы данных. Однако, Django предоставляет более простой способ выполнять SQL в базе данных.

Если вам интересно, запустите следующие команды:

• – Проверяет на ошибки структуру ваших моделей.

• – Выводит (такие как изменения в таблице или дополнительные правила) определенные для приложения.

• – Выводит необходимые DROP TABLE запросы для этого приложения, учитывая таблицы, которые уже существуют в базе данных (если такие есть).

• – Выводит CREATE INDEX запросы для приложения.

• – Выводит комбинацию SQL запросов команд , , из .

Изучение вывода этих команд может помочь вам понять что на самом деле происходит.

Теперь, выполните команду снова, чтобы создать таблицы для этих моделей в базе данных:

python manage.py syncdb

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

Почему Python?

Python является одним из наиболее динамично развивающихся языков программирования в мире благодаря своей простоте и универсальности. Он достаточно прост в изучении и понимании синтаксиса. При этом достаточно мощный по своим возможностям. На нем можно писать как простенькие скрипты, так и сложные приложения и даже некоторые виды игр. Еще одним плюсом языка Python является его кросс-платформенность, т.е. написанный код будет работать на любой операционной системе и на устройствах различного типа – от компьютера до смартфона. Главное – установить интерпретатор языка Python на устройство в нужной версии и можно выполнять код. Если вы новичок в программировании и разработке программного обеспечения, то изучение языка Python будет отличным вариантом для применения получаемых знаний на практике, а мощь и универсальность языка позволит легко переключаться между проектами различного назначения без необходимости кардинального переобучения.

Слой Views

Слой View в контексте Django отвечает за представление и обработку пользовательских данных, в нем мы описываем, какие данные нам нужны и как мы хотим их представить. Если вспомнить то, о чем мы говорили в начале, то можно сразу сделать вывод, что во views не нужно писать бизнес-логику, иначе мы смешиваем логику представления данных с бизнес-логикой. Даже если считать, что views в Django это контроллеры, то размещать в них бизнес-логику тоже не стоит, иначе у вас получатся ТТУКи («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers).

Но часто можно увидеть что-то подобное:

По дефолту, в ModelViewSet для сохранения и обновления данных используется сериалайзер, что не входит в его обязанности. Это можно исправить, полностью переопределить метод perform_create  (не вызывать super, но тогда встает вопрос об объективности наследования от ModelViewSet). Можно написать кастомные методы в ModelViewSet или написать кастомные APIView:

В отличии от слоя serializers, мы теперь легко можем поместить нашу логику получения заказов в слой views.

Тем самым, ограничив не только получение списка, но и другие методы CRUD, что, иногда, очень удобно и быстро. Также, можно переопределить каждый метод по отдельности.

Получается такая схема:

Стоит помнить, что мы отказались от использования save у serializers. В таком случае слой serializers остается “чистым” и выполняет только “правильные” обязанности.

Плюсы данного подхода

Легко делать CRUD

Django и DRF предоставляют очень удобные инструменты, с помощью которых можно легко создавать CRUD и views не исключение.

Минусы данного подхода

Нарушение идей MVC

Мы смешиваем в одном слое логику представления данных и бизнес-логику приложения.

Нельзя переиспользовать

Не получится переиспользовать логику одной view в другой view, или в каком-то другом компоненте. Так же будут проблемы, если мы захотим вызывать нашу бизнес-логику из других интерфейсов, например, из Celery задач.

Высокая зависимость от фреймворка

Высокая зависимость от DRF View или Django View. Если мы захотим поменять способ обработки запроса и отказаться от views, то придется переносить или переписывать нашу логику. Будет сложно переехать с Django View на DRF View или наоборот.

Сложно тестировать

Достаточно сложно протестировать код во views независимо от serializers и остальной инфраструктуры Django + придется использовать http client для тестирования.

Сложно поддерживать

Со временем views разрастаются, часть логики переносится в Celery задачи, часть в модели, код во views дублируется, так как их нельзя переиспользовать — все это приводит к тому, что проект сложно поддерживать.

Правильные обязанности слоя 

Обработка запроса

Во view мы принимаем и обрабатываем запрос клиента, подготавливаем данные для передачи в бизнес-логику.

Делегирование сериализации данных сериалайзерам

Всю логику сериализации данных должны выполнять сериалайзеры.

Вызов методов бизнес-логики

После подготовки и сериализации данных вызывается интерфейс бизнес-логики.

Логика представления данных

Мы должны обработать ответ от методов бизнес-логики и предоставить нужные данные клиенту.

Заключение

Вывод примерно такой же как и с serializers — в views не стоит размещать бизнес-логику.

Стоит отказаться от ModelViewSet и миксинов, так как они используют сериалайзеры для сохранения данных, вместо этого использовать обычные APIView или GenericAPIView.

Если вам нужен только CRUD, то можно использовать подход который предоставляет ModelViewSet и не усложнять себе жизнь.

Установка и настройка Django

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

Перед началом работы с Django нам естественно надо установить интерпретатор Python. Подоробнее об этом можно почитать
здесь.

Существуют разные способы установки Django. Рассмотрим рекомендуемый способ.

Для установки нам потребуется пакетный менеджер pip. Менеджер pip позволяет загружать пакеты и управлять ими.
Нередко, при установке python также устанавливается и менеджер pip. В этом случае мы можем проверить версию менеджера, выполнив в командной строке/терминале следующую команду:

pip -v

Но если pip не установлен, то мы увидим ошибку типа .
В этом случае нам надо установить pip.

python get-pip.py

Если pip ранее уже был установлен, то можно его обновить с помощью команды

pip install --upgrade pip

Установка виртуальной среды

Виртуальная среда или virtualenv не является неотъемлимой частью разработки на Django. Однако ее рекомендуется использовать, так как она
позволяет создать множество виртуальных сред Python на одной операционной системе. Благодаря виртуальной среде приложение может запускаться независимо от
других приложений на Python.

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

Для работы с виртуальной средой вначале необходимо установить пакет virtualenv с помощью следующей команды

pip install virtualenv

Теперь создадим вируальную среду. Вначале определим каталог для виртуальных сред, где будут располагаться все связанные файлы и папки.
Например, пусть это будет каталог C:\virtualenv.
Прежде всего перейдем в командной строке/терминале в этот каталог с помощью команды cd. Затем для создания виртуальной среды выполним следующую команду:

virtualenv hello

Команде virtualenv передается название среды, которая в данном случае будет называться «hello».

После этого в текущей папке будет создан подкаталог hello.

Активация виртуальной среды

Для использования виртуальную среду надо активировать. И каждый раз, когда мы будем работать с проектом Django, связанную с ним виртуальную среду
надо активировать. Например, активируем выше созданную среду, которая располагается в текущем каталоге в папке hello.
Если наша ОС — Windows, то в папке hello/Scripts/ мы можем найти файл activate.bat, который активирует виртуальную среду.
Поэтому для Windows активация виртуальной среды будет выглядеть таким образом:

hello\Scripts\activate.bat

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

source ~/.hello/bin/activate

После окончания работы с виртуальной средой мы можем ее деактивировать. Для этого в той же папке hello/Scripts/
мы можем найти файл deactivate.bat и таким же образом запустить его.

Установка Django

После активации виртуальной среды для установки Django выполним в консоли следующую команду

pip install django

Она устанавливает последнюю версию Django.

НазадВперед

Нас Django вкус волнует и манит

Прошло уже несколько недель, как официально вышла 3 версия Django. Я работал с этой версией ещё до публикации официального релиза и, к сожалению, заметил, что развитие Django сильно замедлилось. Версия 1.3 от 1.7 отличается в разы, а вот 3 версия содержит косметические изменения ветки 2 и не более.
Мой проект winePad стартовал с версии Django 1.3, и к текущему моменту в нем переопределено около 12% внутреннего кода Django.
Видя код новой версии, я понимаю, что правки, которые я или мои коллеги сделали при работе с предыдущими версиями поедут и дальше. А глядя на roadmap и вялотекущие изменения официального репозитория ждать, что ошибки будут скорректированы в будущих версиях — не приходится.
Вот о работе над ошибками я и хочу рассказать: