Как мы все знаем, django использует MVT (модель-представление-шаблон) для проектирования веб-приложений.

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

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

Набор базовых классов и примесей в django разработан для максимальной гибкости. Давайте посмотрим, как мы можем использовать базовое представление на основе классов в django, используя наследование классов представления, и сравним его с представлением на основе функций.

#views.py using View class inheritance
from django.views import View
from django.http import HttpResponse, HttpRequest

class IndexView(View):
    def get(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from indexview")

    def post(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from indexview in post method")

#views.py function based view
from django.http import HttpResponse, HttpRequest

def index(request: HttpRequest):
    if request.method == "GET":
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from index funcion view")
    elif request.method == "POST":
        # imagine 10 line of view logic here
        return HttpResponse("Hello world from index funcion view in post method")

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

Чтобы зарегистрировать представление на основе класса в конфигурации URL-адреса, мы должны вызвать метод класса as_view(), который по сути преобразует представление класса в вызываемую функцию. эта преобразованная функция вызовет setup() для инициализации своего атрибута, а затем вызовет диспетчеризацию(), чтобы проверить, какой метод у пользователя есть (GET, POST или другой метод), и подключит метод запроса к соответствующему методу сопоставления, который изначально имелся в представлении на основе класса.

#urls.py

from django.urls import path
from myapp.views import IndexView, index

urlpatterns = [
    path("", IndexView.as_view(), name=IndexView.__name__), 
    path("index/", index, name=index.__name__),

]

Представление на основе классов также поддерживает все http shourtcut, которые есть в django, например функцию render() для рендеринга шаблона. Вот модифицированный пример django cbv с использованием ярлыка рендеринга и взаимодействия с платформой сообщений django

class IndexView(View):
    def get(self, request: HttpRequest):
        # imagine 10 line of view logic here
        return render(request, "GEtindex.html")

    def post(self, request: HttpRequest):
        # imagine 10 line of view logic here
        messages.add_message(request, messages.INFO, "POST Success") #add display success message here by django messages framework
        return render(request, "POSTindex.html")

В целом представление на основе классов django позволяет разработчику лучше писать, чтобы понять логику представления. Чем сложнее логика представления, я почти уверен, что ее будет труднее читать, если мы просто будем использовать представление на основе функций (слишком много операторов if для проверки того, что метод используется пользователем для примера) и его трудно масштабировать, в то время как django cbv предназначен для того, чтобы разбить нашу логику представления на несколько методов, таких как метод get и post. и его можно снова использовать в наследовании, если хотите, хотя я могу утверждать, что чем больше наследования у нас в классе, тем труднее его читать из-за его абстракции.

вы можете узнать больше о представлении на основе классов в документации django, начиная здесь, здесь, здесь

Также хорошей альтернативной документацией, посвященной представлениям на основе классов django, является ccbv.co.uk