Django nutzt ein etwas anders benanntes, aber im Grunde sehr ähnliches Entwurfsmuster (Design Pattern), wie MVC (Model, View, Controller) und nennt es MTV (Model - Template - View).

Das Model enthält dabei das Datenmodel und die Templates beschreiben (definieren), wie man die Daten aus dem Datenmodel präsentiert bekommt.

Die View sorgt bei Django für die Beschaffung und Aufbereitung der "angeforderten" Daten. Es wird beschrieben, welche Daten man "sichten" möchte.

(Im klassischen MVC Design Pattern sehen viele diese Rolle beim Controller und die View würde für die Visualisierung stehen. Egal wie man die einzelnen Schichten bezeichnet, im Grunde werden einzelne Aufgabenbereiche sauber getrennt, damit die Umsetzung auch langfristig von vielen verstanden wird.)

Entwurfsmuster sind, wie der Name schon sagt, erst einmal nur Muster (Vorschläge) für den Entwurf (die Umsetzung). Aber natürlich bietet Django schon fertige Lösungen für das eigene Muster an.

Bei den Views gibt es grob drei Möglichkeiten (Ansätze) diese in Django umzusetzen:

1. Function-Based Views (FBV) - Funktionsbasierte Sichten sind dabei die oft am einfachsten nachvollziehbare, da sehr transparente Art eine View umzusetzen. Man definiert (def) einfach eine Python-Funktion, die eine HTTP-Anfrage (request) empfängt und eine HTTP-Antwort (response) zurückgibt (return). Um die HTTP-Antwort nicht im Quelltext der View hinterlegen zu müssen und die Vorzüge eines separaten Templates zu nutzen. Gibt es noch eine Hilfsmethode, quasi eine Abkürzung in dem Paket "django.shortcuts" namens "render". Hiermit kann der Antwort der FBV direkt ein Template (HTML-Datei) und ein Datenkontext (context) mitgeben werden.

2. Class-Based Views (CBV) - Bei den klassenbasierten Sichten definiert man die View über eine Python-Klasse (class), die Klasse erweitert (basiert) dabei auf der von Django bereitgestellten, abstrakten (d.h. für die Nutzung noch zu erweiternde) Klasse "django.view.generic.View". Eine CBV ist im Grunde eine Klasse, die eine FBV umhüllt (wraps). Und z.B. für unterschiedliche HTTP Methoden (POST, GET...) auch jeweils eigene Methoden bereitstellt. CBV wirken im Vergleich zu FBV einwenig wie Zauberei. Natürlich könnte man sich die interne Umsetzung einer CBV genauer anschauen, aber es ist ja gerade der Sinn eine etablierte Lösung wiederzuverwenden (code reuse).

3. Generic Class-Based Views (GCBV) - Exemplarische klassenbasierte Sichten gehen noch einen Schritt weiter und liefern Lösungen für bestimmte Arten von häufig vorkommenden Anfragen. D.h. sie sind selbst vorgefertigte Implementierungen von CBV's. Typische Sichten sind dabei die CRUD Anfragen, create, read, update, und delete.

Letztendlich sind also alle Views auf eine Art funktionsbasiert. Manche sind transparenter (FBV), erfordern dafür aber auch mehr Eigenarbeit, andere funktionieren nahezu automatisch (GCBV) und erfordern aber für das Verständnis etwas mehr Hintergrundwissen.

Bleibt die Frage, welchen Umsetzungsansatz man den nun wählen sollte? Und die Antwort lautet ganz einfach..."alle".

Es kommt einfach auf die Situation an. Man kann und sollte jedoch meiner Meinung nach in folgender Reihenfolge entscheiden, welchen Ansatz man für den konkreten Fall am Besten nutzt.

1. GCBV - immer wenn "Standard"-Sichten ohne viel Schnick-Schnack ausreichen

2. CBV - können immer genutzt werden, da eigene Funktionalität genau wie bei FBV frei hinzugefügt werden kann

3. FBV - kann / sollte man dann nutzen, wenn mehr Transparenz sinnvoll / nötig ist