Membedah arsitektur Model-Template-View (MTV) Django, perbedaan project versus app, serta siklus hidup satu request dari URLconf → View → Model → Template. Memahami "sensible defaults" dan mengapa admin panel bisa hadir otomatis di setiap project Django.

Setelah di episode 1 kita memahami sejarah dan filosofi "batteries-included" Django, pada episode ini kita membedah arsitektur inti yang membuat semua itu bekerja: pola Model-Template-View (MTV). Ini adalah fondasi konseptual yang paling penting sebelum kalian menulis project pertama di episode 3.
Mengapa harus paham arsitektur dulu? Karena hampir semua kesalahan di Django — view yang terlalu gemuk, template yang mengecek logika di luar kewenangannya, atau model yang menyimpan data redundant — berakar dari tidak memahami pembagian tanggung jawab. Memahami MTV akan membuat kalian menulis kode yang bisa dipelihara, dan memahami alur request akan membuat kalian tahu persis di mana harus debugging.
Developer dari framework lain sering bertanya: "Django MVC-nya mana?" Jawabannya: Django memakai MTV, tetapi perannya sejajar dengan MVC.
| MVC (klasik) | MTV (Django) | Peran |
|---|---|---|
| Model | Model | Data & aturan bisnis, disimpan di database via ORM |
| View | Template | Presentasi: bagaimana data ditampilkan |
| Controller | View | Logika yang memutuskan data apa yang dikirim ke template |
Dalam MVC klasik, controller adalah "otak" yang menghubungkan model dan view. Di Django, peran itu dimainkan oleh View (Python function/class), sementara istilah "View" di MVC diambil alih oleh Template. Ini hanya perbedaan penamaan — polanya tetap memisahkan data, logika, dan presentasi.
Model adalah representasi Python dari tabel database. Setiap class model mewarisi models.Model dan diubah menjadi tabel melalui migrations (episode 7). Contoh kecil:
from django.db import models
class Post(models.Model):
title = models.CharField(max_length=200)
body = models.TextField()
published = models.BooleanField(default=False)Model menyimpan aturan data: tipe field, relasi (ForeignKey, ManyToMany, OneToOne), validasi, dan logika bisnis yang berkaitan dengan data. Seluruh detail ORM dan QuerySet kita bahas mendalam di episode 6 dan 14.
Template adalah file HTML yang disisipi bahasa template Django (DTL). Ia hanya bertanggung jawab atas presentasi — tidak boleh berisi logika bisnis berat.
<h1>{{ post.title }}</h1>
<p>{{ post.body }}</p>Sintaks {{ ... }} menampilkan variabel, dan {% ... %} menjalankan tag seperti {% if %} atau {% for %}. Seluruh detail template, inheritance, dan custom tag kita bahas di episode 5.
View adalah function atau class Python yang menerima HttpRequest dan mengembalikan HttpResponse. Ia membaca data dari model (atau API), lalu merendernya ke template.
from django.shortcuts import render
from .models import Post
def post_detail(request, pk):
post = Post.objects.get(pk=pk)
return render(request, "blog/post_detail.html", {"post": post})Perbandingan Function-Based Views (FBV) vs Class-Based Views (CBV) kita bahas lengkap di episode 4.
Django membedakan dua level organisasi yang sering membingungkan pemula:
settings.py, urls.py root) dan satu atau lebih app. Dibuat dengan django-admin startproject.django-admin startapp.Analogi dunia nyata: project adalah perusahaan, app adalah divisi. Divisi pemasaran, divisi keuangan, dan divisi IT berbagi kebijakan perusahaan (settings) tetapi masing-masing punya tanggung jawab dan file sendiri. Django punya lusinan app bawaan — django.contrib.admin, django.contrib.auth, django.contrib.sessions — dan kita akan menambah app buatan sendiri mulai episode 3.
Tip
Aturan praktis: pisahkan app berdasarkan domain, bukan berdasarkan lapisan teknis. Jangan membuat app bernama models atau views — buat blog, comments, accounts. Ini menjaga kode tetap terorganisir saat project tumbuh, dan memudahkan re-use app antar project.
Ketika browser mengirim request ke server Django, alurnya seperti ini:
Langkah detailnya:
urlpatterns.HttpRequest.Pemahaman alur ini krusial: ketika ada bug, kalian bisa memetakan "error terjadi di lapisan mana" dengan cepat. Middleware kita bedah di episode 10 dan 18; render ke response ini menjadi tema episode 4–5.
Salah satu hasil arsitektur MTV + batteries-included adalah Django Admin: karena model mendeskripsikan struktur data secara deklaratif, Django bisa men-generate panel CRUD untuk semua model tanpa menulis satu baris view atau template. Admin bawaan ini langsung aktif saat project pertama dibuat (kita kustomisasi di episode 8).
Filosofi "sensible defaults" juga terlihat di settings.py: DEBUG, ALLOWED_HOSTS, INSTALLED_APPS, dan DATABASES sudah punya nilai awal yang aman dan bisa dipakai langsung. Ini berbeda dengan framework yang memaksa kalian memilih konfigurasi sebelum memahami konsekuensinya.
INSTALLED_APPS = [
"django.contrib.admin",
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.messages",
"django.contrib.staticfiles",
]
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.common.CommonMiddleware",
"django.middleware.csrf.CsrfViewMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.messages.middleware.MessageMiddleware",
"django.middleware.clickjacking.XFrameOptionsMiddleware",
]Setiap baris di atas punya peran spesifik — dan kita akan mengubah-ubahnya sepanjang series: menambah app (episode 3), menyesuaikan middleware (episode 10), mengganti template engine (episode 5), dan meng-hardening security (episode 18).
Inti yang harus dibawa pulang:
Di episode 3 selanjutnya, kita langsung membuat project Django pertama — django-admin startproject devblog, startapp blog, membedah manage.py dan settings.py, serta menjalankan development server untuk pertama kali. Pastikan venv episode 0 masih aktif, karena hands-on dimulai sekarang!