Entity Framework Core: Kodla Yönetilen Bir Veritabanı Katmanı
SQL sorgusu yazmak yerine veritabanı şemasını kod üzerinden yönetiyorum.
Mert Celal Yılmaz · Full Stack Developer · Güncellendi:
Bir veritabanı şemasını değiştirmek için elle tablo düzenlemek yerine, bunu tamamen kod üzerinden yönetmek de mümkün. Entity Framework Core, .NET tarafında bunu sağlayan ORM katmanı: sınıflarını, yani entity'lerini tanımlıyorsun, EF Core bunları tablolara eşliyor. Sorguları LINQ ile yazıyorsun, arkada bu sorgular SQL Server için uygun SQL'e çevriliyor. Code-first yaklaşımda şema, migration'larla adım adım ilerliyor; yani kod gibi versiyonlanıyor ve git geçmişinde takip edilebiliyor.
Apartman yönetim sistemi ve kurumsal iş yönetim platformunda EF Core, SQL Server üzerindeki ORM katmanı olarak çalışıyor. Bir entity'ye yeni alan eklediğimde, bir ilişkiyi değiştirdiğimde ya da bir index eklemem gerektiğinde migration oluşturup veritabanına uyguluyorum. Bu adım ayrı bir DBA süreci değil, bir feature'ı bitirmeden önce yapılan sıradan bir iş.
Migration dosyalarının geçmişine bakınca projenin veritabanı tarafının zaman içinde nasıl şekillendiğini de görebiliyorsun. Hangi tabloya ne zaman hangi alan eklendi, hangi ilişki ne zaman değişti, hepsi orada duruyor. Kod ile şema arasındaki bu senkron, özellikle refactor yaparken işi bayağı kolaylaştırıyor.
DbContext'in değişiklik takibi (change tracking) snapshot tabanlı çalışır: bir entity yüklendiğinde EF Core onun o anki durumunu bellekte saklar, SaveChanges çağrıldığında bu snapshot'la mevcut durumu karşılaştırıp sadece değişen kolonlar için UPDATE cümlesi üretir. Apartman yönetim sisteminde aidat kayıtları gibi sık güncellenen tablolarda bu, tüm satırı değil sadece değişen alanları yazması anlamına gelir.
Migration'ları otomatik ürettirmenin gözden kaçan bir tuzağı var: EF Core bir kolonun yeniden adlandırıldığını anlayamıyor, onu drop+add olarak yorumluyor ve bu veri kaybına yol açabiliyor. Bu yüzden üretilen migration dosyasını production'a uygulamadan önce elle gözden geçirmek gerekiyor, özellikle kolon yeniden adlandırma veya tip değişikliği içeren senaryolarda. Kurumsal iş yönetim platformunda büyük tablolarda böyle bir migration'ı doğrudan çalıştırmak yerine önce staging ortamında denemeyi tercih ediyorum.