EF Core Tracking Performans Optimizasyonu

EF Core aracılığıyla veritabanından çekilen sorgular neticesinde gelen dataların otomatik olarak takip edilmesini sağlayan tracking mekanizmasıdır.

DbContext aracılığıyla veritabanından çekmiş olduğum bütün datalar otomatik olarak Tracking mekanizması tarafından takibe alınır. DbContext üzerinden sorgulama neticesinde gelen bu datalar üzerinde manipülasyon işlemleri yapıyoruz. Ve bu manipülasyon işlemleri neticesinde SaveChanges dediğimizde yapılan değişikliklere uygun şekilde veritabanında değişiklikleri görüyoruz ya işte EF burdaki değişikliğin ne olduğunun farkına Tracking mekanizması sayesinde varıyor. Yani tracking mekanizması sayesinde takip edilen nesne üzerinde yapılan değişikliğin delete mi yoksa update mi olup olmadığını rahat bir şekilde mekanizma anlıyor ve bunu fiziksel veritabanına işliyor. 

EF Core üzerinden yapılan tüm sorgulamalarda default olarak tracking mekanizması devreye girer ve gelen datalar takip edilir. 

Tracking mekanizmasında her bir sorgulama neticesinde gelen datalar otomatik track ediliyor yani takip ediliyor. Takip edilen datalar üzerinde bir manipülasyon yani update ya da delete işlemi yapacaksam, takip mekanizması sayesinde bu değişikliklerin farkına varılıp otomatik olarak bu değişikliklere dair sql cümlecikleri oluşturulup fiziksel veritabanına yansıtılabilir. Burada hız kazandırıyor. Ancak her zaman bu şekilde sorgulama yapmıyoruz, sadece manipülasyon amaçlı sorgulama yapmıyoruz. Veritabanındaki bütün ürünleri sadece listelemek sadece son kullanıcıya göstermek için çekiyor olabilirim. Diyelim ki 1000 tane ürünüm var, bu 1000 tane ürünü EF Core aracılığıyla sorgulayıp çektikten sonra ben bunların üzerinde delete ya da update yapmayacaksam tracking mekanizmasının burada devrede olması sizce ne kadar mantıklı ?  Değil… Burada track etmek yani takip mekanizmasının çalışması demek bir maliyettir.

EF Core üzerinden gelen sorgulama neticesinde gelen datalardan istediğimin track edilip istemediğimin edilmemesini sağlayabilmek için optimizasyon yapmamız gerekir.

_productReadRepository de çekilen bir datanın üzerinde yapılan değişikliği nasıl oluyor da _productWriteRepository üzerinden SaveAsync  yapıyoruz?

İşin sırrı Scope da, herhangi bir requestle özel bir tane instance oluşturuyordu ve bütün taleplerde o instance ı gönderiyordu. (DbContext ve diğerleri için Scoped kullandığımız için)

Scope olduğundan dolayı hem write hem de read operasyonlarında kullanacağımız dbcontext aynı olacağından dolayı, bu ikisi de arka planda aynı dbcontext i kullandığından dolayı, veriyi sorgulama amaçlı kullandığımız dbcontext her  neyse aynı requestte bunu talep eden bu dbcontext i talep eden diğer writerepository de aynı instance ı elde edecektir. Biz mevcut olan sorgulamayı yaptığımız dbcontext üzerinden datayı elde ettiğimiz dbcontext üzerinden savechanges fonksiyonunu çağırmış olacağız, scoped davranışından kaynaklanmaktadır.

Gelecek olan datayı (false yaptık) track etme dedik. Takip edilmesini, bunun üzerinde yapılan değişiklikleri herhangi bir şekilde sorguya dönüştürülmesini istemiyorsam false olarak işaretliyorum. Bundan sonra ne kadar değişiklik yaparsak yapalım, ne kadar savechanges fonksiyonunu tetiklersek tetikleyelim ilgili değişiklikler fiziksel veritabanına yansıtılmayacaktır. Çünkü artık ilgili sorgu neticesinde context üzerinden gelen data tracking mekanizması ile takip edilmeyeceğinden dolayı değişiklikler uygulanmayacaktır.

İnternet sitesi https://abdullahsarihan.com
Yazı oluşturuldu 108

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Benzer yazılar

Aramak istediğinizi üstte yazmaya başlayın ve aramak için enter tuşuna basın. İptal için ESC tuşuna basın.