Como todos sabemos, Django usa MVT (model-view-template) para seu design no desenvolvimento de aplicações web.

View em si é uma chamada que recebe uma solicitação e retorna uma resposta. é mais do que apenas uma função, pois o Django fornece algo chamado Class Based View, para que o desenvolvedor possa escrever uma visão usando, bem, uma abordagem baseada em classe ou você pode dizer uma abordagem OOP. Esta Visualização Baseada em Classe foi projetada para que possamos estruturar nossas visualizações e possam ser reutilizadas pelo poder da herança e mixins.

Como bem documentado nos documentos do Django, um dos problemas com a visão baseada em funções é que não há como estendê-las ou personalizá-las além de algumas opções de configuração, limitando sua utilidade em muitas aplicações do mundo real.

O kit de ferramentas de classes base e mixins no Django é projetado para máxima flexibilidade. Vamos dar uma olhada em como podemos usar a visualização baseada em classe mais básica no Django usando a herança de classe View e compará-la com a visualização baseada em função.

#views.py usando herança de classe View de django.views importar Visualização de django.http importar HttpResponse, HttpRequest classe IndexView (Visualizar): def get(self, solicitação: HttpRequest): # imagine uma lógica de 10 linhas de visão aqui return HttpResponse("Olá mundo do indexview") def post(self, solicitação: HttpRequest): # imagine uma lógica de 10 linhas de visão aqui return HttpResponse("Olá mundo do indexview no método post")

#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 visualização baseada em função de django.http importar HttpResponse, HttpRequest índice def (solicitação: HttpRequest): se request.method == "GET": # imagine uma lógica de 10 linhas de visão aqui return HttpResponse("Olá mundo da visualização da função de índice") elif request.method == "POST": # imagine uma lógica de 10 linhas de visão aqui return HttpResponse("Olá mundo da visualização da função de índice no método post")

#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")

Se você observar acima, uma visualização baseada em classe permite que você responda a diferentes métodos de solicitação HTTP com diferentes métodos de instância de classe, em vez de ramificar condicionalmente o código dentro de uma única função de visualização. agora imagine em cada visualização acima que adicionamos 10 linhas de lógica a cada método, você deve saber qual é mais fácil de percorrer.

Para registrar a visualização baseada em classe na configuração do URL, devemos chamar o método de classe as_view() que basicamente converterá a visualização de classe em uma função que pode ser chamada. esta função convertida chamará setup() para inicializar seu atributo e então chamará dispatch() para verificar qual método o usuário possui (um GET, POST ou outro método) e conectará o método de solicitação ao método de correspondência correspondente que a visualização baseada em classe originalmente possui

#urls.py do caminho de importação do django.urls de myapp.views importar IndexView, índice padrões de url = [ caminho("", IndexView.as_view(), nome=IndexView.__name__), caminho("índice/", índice, nome=índice.__nome__), ]

#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")

a visualização baseada em classe também suporta todos os http shourtcut que o Django possui, como a função render() para renderizar um modelo, aqui está um exemplo modificado do Django cbv usando o atalho de renderização e cooperando com a estrutura de mensagens do Django

class IndexView (Visualizar): def get(self, solicitação: HttpRequest): # imagine uma lógica de 10 linhas de visão aqui retornar renderização (solicitação, "GEtindex.html") def post(self, solicitação: HttpRequest): # imagine uma lógica de 10 linhas de visão aqui messages.add_message(request, messages.INFO, "POST Success") #add exibe mensagem de sucesso aqui pelo framework de mensagens Django retornar renderização (solicitação, "POSTindex.html")

#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")

A visualização geral baseada na classe Django permite que o desenvolvedor escreva melhor para entender a lógica da visualização, quanto mais complexa for a lógica da visualização, tenho certeza de que será mais difícil de ler se apenas usarmos a visualização baseada em função (muitas instruções if para verificar o que são usados ​​​​pelo usuário, por exemplo) e difíceis de escalar, enquanto o django cbv foi projetado para quebrar nossa lógica de visualização para vários métodos, como o método get e post. e pode ser usado novamente em herança se você quiser, embora eu possa argumentar que quanto mais herança tivermos em uma classe, será mais difícil de ler devido à sua abstração.

você pode verificar mais sobre a visualização baseada em classe na documentação do Django começa aqui, aqui, aqui

Também um bom documento alternativo que se concentra na visualização baseada em classe Django é ccbv.co.uk