Vad är MVT-arkitekturen?

Question

Accepted Answer

Django följer **MVT (Model-View-Template)** arkitekturen — sin variant på det klassiska MVC-mönstret. Det separerar en applikation i tre lager: **Models** (data), **Views** (logik) och **Templates** (presentation). Att förstå lagren klargör var varje kodbit hör hemma. ## De tre lagren ```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 ``` ## Hur de arbetar tillsammans (request-flödet) ```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 %} ``` Vyn binder det ihop: den tar emot requesten, frågar models för data och renderar en template med den datan för att producera svaret. ## 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). ``` Namnsättningen skiljer sig från MVC: Djangos **View** spelar rollen av MVCs *Controller* (request-hanteringlogik), och Djangos **Template** spelar MVCs *View* (presentation). Ramverkets routing hanterar dispatch. ## Varför denna separation är viktig ```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 ``` ## Varför det spelar roll MVT-arkitekturen är det grundläggande strukturella mönstret för varje Django-applikation — att förstå det säger dig **var varje kodbit hör hemma** (datadefinitioner i models, request-hanteringlogik i views, HTML-presentation i templates), vilket är essentiellt för att organisera ett Django-projekt korrekt. Separationen av ansvar som det tillämpar gör applikationer underhållbara (ändra presentation utan att röra logik), testbara (testa views och models oberoende) och återanvändbara. Lika viktigt är att förstå **MVT-vs-MVC-mappningen** — en vanlig källa till förvirring — där Djangos "View" faktiskt är controller-ekvivalenten (logiken) och Djangos "Template" är view-ekvivalenten (presentationen); att veta detta klargör namngivningen och hjälper utvecklare från MVC-ramverk. Request-flödet (URL routing → view → models → template → response) är mentalmodellen för hur varje Django-request bearbetas, vilket gör MVT grundläggande, måste-kunna-kunskap som ligger till grund för hur du strukturerar och resonerar om all Django-kod.