← Back to list

Django’da MVT Mimarisi: Migration Mantığı ve Modelden Veritabanına Geçiş

1. Giriş

Muratisik · 2026-05-31 13:27 · 0 claps · 3.0 min read
#python #django #mvt #backend-development #web-development
Open on Medium ↗
Wiki topics: 🌐 · Web Development

Django’da MVT Mimarisi: Migration Mantığı ve Modelden Veritabanına Geçiş

Photo by Hitesh Choudhary on Unsplash

Photo by Hitesh Choudhary on Unsplash

1. Giriş

Herkese merhaba! Backend (arka uç) geliştirme dünyasına merak saldıysanız, yolunuzun bir şekilde Python ve onun meşhur web framework’ü Django ile kesişmesi kaçınılmazdır. Ben de bir backend öğrencisi olarak bu yazımda, Django’nun temelini oluşturan o meşhur MVT mimarisinden ve başlarda “bu ne işe yarıyor” dediğim ama kullanmaya başlayınca hayat kurtaran “Migration” (veritabanı göçü) mantığından bahsedeceğim. Çayınız kahveniz hazırsa, arka planda işlerin nasıl yürüdüğüne birlikte bakalım.

2. Django MVT Mimarisi Nedir?

Django, projeleri daha düzenli ve yönetilebilir tutmak için MVT (Model-View-Template) adını verdiğimiz bir mimari kullanır. Bu yapı aslında yazılım dünyasında çok daha bilinen MVC (Model-View-Controller) mimarisine fazlasıyla benzerlik gösterir.

Django, kullanıcıdan gelen istekleri yönlendirme ve arka plandaki trafik kontrolü gibi yorucu işleri bizzat kendi üstlenir. Geriye kalan görevleri de üç ana parçaya ayırır: Verilerimizi tuttuğumuz kısım (Model), işin beyin kısmının çalıştığı yer (View) ve kullanıcının ekranda gördüğü arayüz (Template). Yani framework bize resmen “Trafik yönetimi bende, sen sadece projene ve içeriğine odaklan” diyerek harika bir kolaylık sağlıyor.

3. Model, View ve Template Bileşenleri

Peki bu üçlü tam olarak ne iş yapıyor? Kısaca özetlemek gerekirse:

  • Model: Veritabanımızla konuştuğumuz yerdir. Uzun SQL sorguları yazmakla boğuşmak yerine, veritabanı tablolarımızı saf Python sınıfları (class) şeklinde burada yazarız.
  • View: Projenin asıl beynidir. Kullanıcıdan gelen istekleri alır, duruma göre Model’e gidip “bana şu veriyi getir” der ve çıkan sonucu ekranda gösterilmesi için Template’e paslar.
  • Template: İşin vitrini. HTML ve CSS kodlarıyla kullanıcının ekranda gördüğü arayüzdür. View’dan gelen veriler burada tasarıma dökülür.

4. Django’da Request-Response Süreci

Diyelim ki bir butona tıkladık veya sitemize girdik. Arka planda trafik şöyle akıyor:

  1. Kullanıcı tarayıcıdan bir istek (Request) atıyor.
  2. Django’nun yönlendiricisi (urls.py) bu adresi yakalayıp, "Bu isteğe hangi View bakacak?" diye buluyor.
  3. İlgili View çalışıyor, gerekirse veritabanından (Model) bilgi çekiyor.
  4. Çektiği bu veriyi Template’e (HTML sayfasına) yolluyor.
  5. Sonunda hazırlanan bu HTML sayfası, kullanıcıya cevap (Response) olarak geri dönüyor.

5. Migration Mantığı: Modelden Veritabanına Geçiş

Gelelim asıl konumuz olan Migration meselesine. Normalde veritabanı tablolarını SQL programları üzerinden elimizle tek tek açarız. Django ise bize “Sen sadece Python kodunu yaz, SQL kısmıyla ben ilgilenirim” diyor. Yazdığımız modellerde (yani veritabanı şemasında) yaptığımız değişikliklerin Django tarafından saklanma ve veritabanına aktarılma şekline Migration denir. Migration dosyaları aslında diskimizde tutulan birer fiziksel kayıt dosyasıdır.

Bu işlem temelde iki komutla gerçekleşiyor:

  • makemigrations: Yazdığımız model değişikliklerini paketleyerek bireysel migration dosyalarına dönüştürür. Bu komut veritabanında henüz bir değişiklik yapmaz, kaynak kod yönetimindeki bir "commit" (kayıt taslağı) mantığıyla çalışır.
  • migrate: Hazırlanan bu migration taslaklarını alır ve veritabanınıza fiilen uygular.

6. Mini Uygulama / Örnek Senaryo

Bu anlattıklarımız havada kalmasın diye çok ufak bir To-Do (Görev Takip) tablosu yapalım. Veritabanımızda eklediğimiz görevlerin adını ve tamamlanıp tamamlanmadığı durumunu tutacağız.

İş akışımız sırasıyla; models.py dosyasında modeli değiştirmek, makemigrations ile taslak oluşturmak ve migrate ile veritabanına uygulamak şeklinde ilerleyecek.

Projemizdeki models.py dosyasına gidip şu kodları yazıyoruz:

from django.db import models

class Task(models.Model):
    # Field to store the task name /Görev adını tutacak alan
    title = models.CharField(max_length=100)

    #Field that stores whether the task is completed (Default: No)/ Tamamlanma durumunu tutacak alan (Varsayılan olarak hayır)
    is_completed = models.BooleanField(default=False)

    def __str__(self):
        return self.title

Gördüğünüz gibi tek satır bile SQL yazmadık. Şimdi bunu veritabanına nasıl aktardığımıza bakalım.

7. Adım Adım Uygulama ve Ekran Görüntüleri

Modelimizi models.py dosyasına kaydettikten sonra, işin sihirli kısmına yani komut satırına geçiyoruz. İlk adım olarak veritabanı planımızı (taslağı) oluşturmak için terminalimizi açıp python manage.py makemigrations komutunu çalıştırıyoruz.

Yukarıdaki ekran görüntüsünde görebileceğiniz üzere Django, “Task” adında yeni bir model oluşturduğumu algıladı ve 0001_initial.py isimli taslağını hazırladı. Şimdi bu taslağı veritabanına gerçekten uygulamak ve tablolarımızı yaratmak için python manage.py migrate komutunu veriyoruz.

8. Sonuç

Toparlamak gerekirse, Django’nun MVT yapısı kodları karmaşadan kurtarıp son derece düzenli hale getiriyor. Migration mantığı ise özellikle projeye sonradan yeni özellikler eklerken veya değişiklik yaparken inanılmaz bir esneklik sağlıyor. Veritabanı tablolarını sadece Python ile yönetebilmek, hem geliştirme hızını artırıyor hem de hata yapma payını en aza indiriyor.

Zaman ayırıp okuduğunuz için teşekkürler, herkese hatasız kodlamalar dilerim!

9. Kaynakça


메타데이터
post_id
bef6355d062a
slug
djangoda-mvt-mimarisi-migration-mantığı-ve-modelden-veritabanına-geçiş-bef6355d062a
url
https://medium.com/@muratisik167/djangoda-mvt-mimarisi-migration-mant%C4%B1%C4%9F%C4%B1-ve-modelden-veritaban%C4%B1na-ge%C3%A7i%C5%9F-bef6355d062a
canonical_url
https://medium.com/@muratisik167/djangoda-mvt-mimarisi-migration-mant%C4%B1%C4%9F%C4%B1-ve-modelden-veritaban%C4%B1na-ge%C3%A7i%C5%9F-bef6355d062a
author_url
https://medium.com/@muratisik167
status
ok
fetched_at
2026-06-12 07:40:50