Django MVT Mimarisi ve Request Lifecycle

Giris

Django, Model-View-Template (MVT) desenine dayanan tam kapsamli bir web framework'udur. Klasik MVC'den farkli olarak 'Controller' rolunu framework'un kendisi ustlenir; gelistirici View katmaninda is mantigini, Model katmaninda veri yapisini ve Template katmaninda sunumu ayirir. Bu ayrim, buyuyen projelerde bakim maliyetini dusurur ve test edilebilirligi artirir.

Bu yazida bir HTTP isteginin WSGI/ASGI sunucusundan baslayarak response donene kadar gectigi tum asamalari inceleyecegiz. Ozellikle urlpatterns, view fonksiyonlari, ORM sorgulari, template rendering ve middleware zincirinin birbirine nasil baglandigini gercek kod ornekleriyle goreceksiniz.

MVT Katmanlarinin Sorumluluklari

Model katmani veritabani semasini ve is kurallarinin veri tarafini tanimlar. View katmani HTTP istegini alir, gerekli is mantigini calistirir ve uygun response'u uretir. Template katmani ise sunum katmanidir; HTML, JSON veya baska formatlarda cikti uretebilir.

Model: models.Model, Manager, QuerySet, signals
View: function-based view (FBV), class-based view (CBV), API view
Template: Django Template Language (DTL), context, inheritance
URL: path(), re_path(), include(), reverse()

Proje ve Uygulama Yapisi

Django projesi settings, urls ve wsgi/asgi gibi global yapilandirmalari icerir. Her app (blog, accounts gibi) kendi models, views, urls ve templates klasorune sahiptir. INSTALLED_APPS listesine eklenmeyen bir app'in modelleri migrate edilmez ve template loader tarafindan bulunamaz.

# mysite/urls.py
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls')),
]

# blog/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('', views.post_list, name='post_list'),
    path('<slug:slug>/', views.post_detail, name='post_detail'),
]

URL Resolver ve View Eslestirme

Bir istek geldiginde Django once ROOT_URLCONF'taki urlpatterns listesini dolasir. path() parametreleri view'a kwargs olarak aktarilir. include() ile alt URL modulleri baglanir ve namespace ile isim cakismalari onlenir.

reverse() ve {% url %} tag'i ile hard-coded URL yerine isimlendirilmis route kullanmak, refactor sirasinda kirilmalari onler. resolve() fonksiyonu debug amacli olarak bir path'in hangi view'a dustugunu gosterir.

from django.urls import reverse
from django.shortcuts import redirect

def create_post(request):
    # ... kayit islemi
    return redirect(reverse('post_detail', kwargs={'slug': post.slug}))

View Katmani: FBV ve CBV

Function-based view'lar acik ve ogrenmesi kolaydir; kucuk endpoint'ler icin idealdir. Class-based view'lar ListView, DetailView, CreateView gibi generic siniflarla tekrar eden CRUD kaliblarini azaltir. Her iki yaklasimda da request.method kontrolu, form validasyonu ve permission kontrolu view sorumlulugundadir.

from django.views.generic import ListView
from .models import Post

class PostListView(ListView):
    model = Post
    template_name = 'blog/post_list.html'
    context_object_name = 'posts'
    paginate_by = 10
    queryset = Post.objects.filter(status='published').select_related('author')

View ince tutulmali; agir is mantigi service katmanina veya model metodlarina tasinmalidir.

Model ve Template Katmani

View, Model uzerinden QuerySet olusturur ve sonuclari template context'ine aktarir. Template loader önce DIRS, sonra app template klasorlerini tarar. extends ve block tag'leri ile layout kalitimi saglanir.

render(request, template, context) ile HTML response
JsonResponse ile API endpoint
Template tag ve filter ile sunum mantigi

# blog/models.py
from django.db import models
from django.contrib.auth import get_user_model

class Post(models.Model):
    title = models.CharField(max_length=200)
    slug = models.SlugField(unique=True)
    body = models.TextField()
    author = models.ForeignKey(get_user_model(), on_delete=models.CASCADE)
    published_at = models.DateTimeField(null=True, blank=True)

    class Meta:
        ordering = ['-published_at']

Request Lifecycle Adim Adim

Django'nun istek isleme dongusu middleware ile baslar ve biter. Her middleware hem request hem response yonunde calisabilir. Asagidaki sirada tipik bir GET istegi islenir.

WSGI/ASGI handler istegi Django'ya iletir
Middleware request asamasi (guvenlik, session, auth)
URL resolver view fonksiyonunu bulur
View calisir; ORM sorgusu ve template render
HttpResponse olusturulur
Middleware response asamasi (gzip, security headers)
Response istemciye doner

# settings.py - middleware sirasi onemlidir
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',
]

Sik Yapilan Hatalar ve Sonuc

View icinde N+1 sorgu problemi, yanlis middleware sirasi ve ROOT_URLCONF hatalari en yaygin uretim sorunlaridir. DEBUG=True iken gosterilen detayli hata sayfalari uretimde asla acik birakilmamalidir.

MVT ayrimini koruyarak, request lifecycle'in her adiminda hangi katmanin sorumlu oldugunu bilmek performans tuning ve guvenlik denetimlerinde buyuk avantaj saglar. Sonraki yazilarda ORM optimizasyonu ve DRF ile API katmanini derinlemesine ele alacagiz.

Is mantigini template icine yazmak
Her view'da ayri ayri auth kontrolu (decorator/mixin kullanin)
include() olmadan monolitik urls.py
Middleware sirasini degistirmeden once dokumantasyonu okumamak

Veri Kullanimi Bildirimi