Was ist die MVT-Architektur?

Question

Accepted Answer

Django folgt der **MVT (Model-View-Template)** Architektur — seiner Variation des klassischen MVC-Musters. Sie teilt eine Anwendung in drei Schichten: **Models** (Daten), **Views** (Logik) und **Templates** (Präsentation). Das Verständnis der Schichten macht deutlich, wo jeder Codeteile hingehört. ## Die drei Schichten ```text Model → the DATA layer: defines structure & talks to the database (the ORM) View → the LOGIC layer: processes requests, fetches data, returns responses Template → the PRESENTATION layer: HTML with placeholders for dynamic data ``` ## Wie sie zusammenarbeiten (der Request-Flow) ```text Request → URLconf (routing) → VIEW → queries MODELS → renders TEMPLATE → Response ``` ```python # MODEL — defines the data (models.py) class Article(models.Model): title = models.CharField(max_length=200) body = models.TextField() # VIEW — the logic: fetch data, pass to a template (views.py) def article_list(request): articles = Article.objects.all() # query the MODEL return render(request, "articles.html", {"articles": articles}) # render a TEMPLATE ``` ```html {% for article in articles %}

{% endfor %} ``` Die View verbindet alles: Sie empfängt den Request, fragt die Models für Daten ab und rendet ein Template mit diesen Daten, um die Response zu erzeugen. ## MVT vs MVC ```text Classic MVC: Model — View — Controller Django MVT: Model — Template — View The mapping (a common point of confusion): Django's VIEW ≈ MVC's CONTROLLER (the logic that handles requests) Django's TEMPLATE ≈ MVC's VIEW (the presentation) Model is the same in both → Django says the framework itself acts as the "controller" (URL routing/dispatch). ``` Die Namensgebung unterscheidet sich von MVC: Djangos **View** spielt die Rolle des MVC *Controller* (Request-Handling-Logik), und Djangos **Template** spielt MVCs *View* (Präsentation). Das Routing des Frameworks handhabt den Dispatch. ## Warum diese Trennung wichtig ist ```text ✓ Separation of concerns — data, logic, and presentation are independent ✓ Maintainability — change the template without touching logic, etc. ✓ Reusability & testability — test views independently, reuse models/templates ``` ## Warum es wichtig ist Die MVT-Architektur ist das grundlegende strukturelle Muster jeder Django-Anwendung — ihr Verständnis sagt dir **wo jeder Codeteile hingehört** (Datendefinitionen in Models, Request-Handling-Logik in Views, HTML-Präsentation in Templates), was für die ordnungsgemäße Organisation eines beliebigen Django-Projekts wesentlich ist. Die Separation of Concerns, die sie erzwingt, macht Anwendungen wartbar (ändere Präsentation ohne Logik zu berühren), testbar (teste Views und Models unabhängig) und wiederverwendbar. Gleich wichtig ist das Verständnis der **MVT-vs-MVC-Zuordnung** — eine häufige Quelle von Verwirrung — wo Djangos "View" tatsächlich das Controller-Äquivalent (die Logik) ist und Djangos "Template" das View-Äquivalent (die Präsentation); wenn du das weißt, wird die Namensgebung geklärt und hilft Entwicklern aus MVC-Frameworks. Der Request-Flow (URL-Routing → View → Models → Template → Response) ist das mentale Modell dafür, wie jeder Django-Request verarbeitet wird, was MVT zu grundlegend, must-know Wissen macht, das unterstützt, wie du alle Django-Code strukturierst und darüber nachdenkst.