Vue basée sur les fonctions FBV Versus CBV Django

Contenu du cours

Qu’est-ce qu’une view Django (en 1 paragraphe)
FBV (Function-Based View)
CBV (Class-Based View)
Tableau comparatif
Conclusion

1. Qu’est-ce qu’une view Django (en 1 paragraphe)

Une view (vue) est une fonction ou une classe qui reçoit une requête HTTP (HttpRequest), exécute une logique (lecture/écriture en base, appels à des services, validation, etc.) et renvoie une réponse HTTP (HttpResponse, JSON, redirection, template rendu…). Elle fait le lien entre l’URL (via urls.py), les modèles et les templates. Dans Django, une view peut être écrite soit comme FBV (Function-Based View), soit comme CBV (Class-Based View), les deux offrant exactement le même pouvoir expressif mais des styles et des outils différents.

2. FBV (Function-Based View)

2.1 Description

Une FBV View est une simple fonction Python qui prend request (et d’éventuels paramètres d’URL) et retourne une HttpResponse. On gère soi-même la logique par méthode HTTP (if request.method == "POST": ...), l’accès aux données et la construction de la réponse.

# views.py
from django.http import HttpResponse, JsonResponse
from django.views.decorators.http import require_http_methods

@require_http_methods(["GET", "POST"])
def article_list(request):
    if request.method == "GET":
        data = [{"id": 1, "title": "Intro"}]
        return JsonResponse(data, safe=False)
    # POST
    # ... création ...
    return HttpResponse(status=201)

# views.py

from django.http import HttpResponse, JsonResponse

from django.views.decorators.http import require_http_methods

@require_http_methods(["GET", "POST"])

def article_list(request):

if request.method == "GET":

data = [{"id": 1, "title": "Intro"}]

return JsonResponse(data, safe=False)

# POST

# ... création ...

return HttpResponse(status=201)

2.2 Avantages

Simplicité : Simples à lire, écrire et déboguer (flow linéaire).
Grande flexibilité : aucun cadre imposé.
Perfection : Parfaites pour des endpoints courts ou très spécifiques.
Décorateurs fonctionnels : très naturels (login_required, permission_required, cache_page, etc.).

2.3 Inconvénients

Répétition : Possible entre vues (gestion manuelle de GET/POST, pagination, formulaires…).
Organisation : Moins modulaire pour des vues complexes (moins de factorisation par héritage/mixins).
Évolutivité : Parfois moindre quand le nombre de cas explose.
Cas d’usage typiques: Petits endpoints API ou webhooks très ciblés.
View : Vues "one-off" avec logique sur mesure.
Prototypes : Rapides, POCs, ou “glue code” minimaliste.

3. CBV (Class-Based View)

3.1 Description

Une CBV View est une classe dérivée de View (ou d’une classe générique) où chaque méthode HTTP est une méthode d’instance (get(), post(), etc.). Django fournit un riche écosystème de Generic Class-Based Views (ListView, DetailView, CreateView, UpdateView, DeleteView, FormView…) et de mixins qui factorisent les patterns courants (CRUD, formulaires, permissions, pagination).

# views.py
from django.views.generic import ListView
from .models import Article

class ArticleListView(ListView):
    model = Article            # -> queryset = Article.objects.all()
    paginate_by = 20           # pagination automatique
    template_name = "articles/list.html"

# views.py

from django.views.generic import ListView

from .models import Article

class ArticleListView(ListView):

model = Article # -> queryset = Article.objects.all()

paginate_by = 20 # pagination automatique

template_name = "articles/list.html"

3.2 Avantages

Réutilisation élevée : génériques + mixins → moins de code répétitif.
Structure : Claire par méthode HTTP et hooks (get_queryset, get_context_data, form_valid, etc.).
Extensibilité : via héritage multiple et composition de mixins (auth, permissions, filtrage…).
Productivité : Forte sur CRUD et formulaires.

3.3 Inconvénients

Courbe d’apprentissage : Plus raide (hiérarchie, resolution order, hooks).
Magie perçue : Le flux peut être moins évident à suivre.
Complexité de lecture : Trop d’héritage/mixins peut complexifier la lecture et le débogage.

3.4 Cas d’usage typiques

CRUD standard : Sur des modèles (List/Detail/Create/Update/Delete).
Vues avec formulaires : validation et redirections.
Endpoints : nécessitant pagination/filtrage/permissions répétitifs.

4. Tableau comparatif

Critère	FBV (Function-Based)	CBV (Class-Based)
Style	Fonction unique	Classe avec méthodes get/post/…
Courbe d’apprentissage	Très faible	Plus élevée (génériques, mixins, hooks)
Verbosité initiale	Faible sur petits cas	Très faible pour CRUD grâce aux génériques
Réutilisation	Faible (copier/coller, décorateurs)	Élevée (héritage, mixins, génériques)
Lisibilité du flux	Linéaire, explicite	Par hooks, parfois moins direct
Extensibilité	Par composition ad hoc	Par héritage/mixins très puissant
Débogage	Simple (point d’arrêt dans la fonction)	Parfois délicat (MRO, surcharges)
Cas idéaux	Endpoints simples, webhooks, logique atypique	CRUD, formulaires, pagination, permissions, patterns répétés
Décorateurs	Très naturels	Via method_decorator ou mixins
Dette technique	Peut croître par duplication	Peut croître par hiérarchie complexe

5. Conclusion

FBV et CBV offrent les mêmes capacités : la différence est surtout de style, factorisation et maintenabilité. Choisissez FBV pour des vues simples, très spécifiques ou expérimentales où la lisibilité linéaire prime. Préférez CBV (et surtout les génériques + mixins) pour des patterns récurrents (CRUD, formulaires, pagination, permissions) afin de réduire le code répétitif et accélérer le développement. Dans une base de code réaliste, les deux coexistent souvent : FBV pour l’atypique, CBV pour le standard. L’important est la cohérence au sein du projet (conventions, mixins maisons, tests) pour garder la courbe de maintenance sous contrôle.

Younes Derfoufi
CRMEF OUJDA

Post Views: 519