Введение в представления (views)

Представления в Django — это сердце вашего веб-приложения. Они обрабатывают запросы пользователей (например, переходы по URL-адресам) и возвращают ответы: HTML-страницы, JSON, текстовые данные и многое другое. Без представлений ваше приложение было бы просто набором статических файлов.

Представьте ресторан: клиент делает заказ, шеф-повар готовит блюдо, официант приносит его клиенту. В Django представление — это шеф-повар. Оно принимает заказ (запрос), подбирает нужные ингредиенты (данные) и подаёт клиенту (браузеру) готовое блюдо (ответ).

Django частично следует принципу MVC (Model-View-Controller), только вот здесь "V" (View) больше напоминает "Controller" из классического MVC. Грубо говоря, представление отвечает за логику обработки запроса: оно решает, что показать пользователю, получив данный запрос.

Роль представления в процессе обработки запросов

Давайте рассмотрим базовый цикл обработки запроса:

1. Пользователь открывает URL-адрес (например, http://localhost:8000/home).
2. Django определяет, какой обработчик запроса соответствует этому URL (используя маршруты в urls.py).
3. Обработчик запроса (наш view) выполняет свою логику. Например:
   • Подтягивает данные из базы данных.
   • Выполняет какую-то вычислительную логику.
   • Формирует ответ (например, HTML-страницу или JSON), который будет отправлен пользователю.

Серверная и клиентская части

Дабы избежать путаницы, уточним: в Django мы работаем на серверной стороне приложения. Мы создаём представления, которые обрабатывают запросы и отправляют готовый результат браузеру. Клиентская часть — это то, что пользователь видит и с чем взаимодействует (HTML, CSS, JavaScript).

Типы представлений в Django

Функциональные представления (Function-Based Views, FBV)

Это самый базовый и широко используемый тип представлений. Как следует из названия, это просто Python-функция, которая принимает объект запроса (обычно request) и возвращает объект ответа (HttpResponse). Вы легко можете создать простейшее представление, которое вернёт строку, JSON или даже файл.

Преимущество FBV — простота. С другой стороны, с ростом сложности проекта такие представления могут становиться громоздкими.

Пример функционального представления (FBV):

from django.http import HttpResponse

def hello_world(request):
    return HttpResponse("Hello, World!")

Представления на основе классов (Class-Based Views, CBV)

В Django есть изящное решение для организации кода представлений — классы вместо функций. Такие представления называются Class-Based Views (CBV). Они позволяют:

• Структурировать код логичнее
• Наследовать и расширять функциональность
• Переиспользовать общие части

А самое приятное — Django уже подготовил набор готовых классов (generic CBV) для типичных задач. Хотите показать список записей? Есть готовый класс. Нужно создать форму? И для этого есть класс. Все CRUD-операции (создание, чтение, обновление, удаление) уже реализованы в этих классах.

Пример простого CBV:

from django.http import HttpResponse
from django.views import View

class HelloWorldView(View):
    def get(self, request):
        return HttpResponse("Hello from CBV!")

FBV или CBV? Когда что использовать?

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

Пример из жизни: FBV — это как однострочное сообщение в чате: быстро, просто, эффективно. А CBV — это как длинное письмо или отчёт: нужно больше структуры, чтобы не запутаться.

Структура простого функционального представления

Давайте посмотрим, как выглядит минималистичное представление:

from django.http import HttpResponse

def my_view(request):
    return HttpResponse("Это мой первый HTTP-ответ!")

Разбор кода:

1. Импорт HttpResponse: этот класс используется для формирования простых текстовых (или HTML) ответов.
2. Функция my_view: каждая функция-представление принимает как минимум один аргумент — объект запроса request.
3. Возврат ответа: метод возвращает объект HttpResponse, который и отправляется клиенту (например, браузеру).

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

Пример простого представления

Создадим простую страницу "О нас". Вот минимальный рабочий пример:

from django.http import HttpResponse

def about_view(request):
    html = """
        <html>
            <head><title>О нас</title></head>
            <body>
                <h1>Привет! Это страница "О нас".</h1>
                <p>Мы любим писать код!</p>
            </body>
        </html>
    """
    return HttpResponse(html)

Это представление уже умеет отдавать HTML-страницу, но пока к нему нельзя обратиться — как к дому без адреса. В следующем разделе мы настроим маршруты (URLs) и оживим наше представление.

Шаблоны вместо "жёсткого" HTML

Рендерить сырой HTML через HttpResponse — не лучшая практика. В следующих лекциях вы узнаете, как использовать систему шаблонов Django, которая позволит отделить логику приложения от пользовательского интерфейса. Но для понимания принципов работы представлений пока это вполне достаточно.

На следующем занятии мы приступим к созданию первых представлений!

1

Задача

Модуль 3: Django, 3 уровень, 0 лекция

Недоступна

Представление с динамическими параметрами

Представление с динамическими параметрами

Открыть