Selam millet! Nasılsınız, iyi misiniz? Bugün yine teknoloji dünyasının derinlerine dalıyoruz ama bu sefer biraz daha ortalarda dolaşacağız sanırım. Hani bazen bir yola çıkarsın ya, ne olacağını tam bilmezsin ama gidesin gelir… İşte tam da öyle bir durumdayız bugün. Dapper ve Entity Framework… İki dev isim, iki farklı dünya. Ben de yıllardır bu ikisiyle haşır neşir olmuş biri olarak, kendi deneyimlerimi, yaşadıklarımı sizinle paylaşmak istedim. Belki sizin de aklınızda soru işaretleri vardır, kim bilir? 🙂 Açıkçası ben de ilk başladığımda çok karışıktı her şey. Hangi birini seçeceğine karar vermek zor oluyordu.
Şimdi öncelikle şunu söyleyeyim, bu ikisi de .NET ekosisteminde veri erişimi için kullanılan harika araçlar. Hani bir inşaatçı düşünün, elinde hem çekiç var hem de matkap. Hangisini kullanacağı işine göre değişir, değil mi? İşte Dapper ve EF de öyle. Biri daha çok “hızlı ve pratik” derken, diğeri daha çok “güvenli ve kapsamlı” olmayı hedefliyor sanki.
Entity Framework, yani namıdiğer EF, aslında Microsoft’un kendi geliştirdiği bir ORM (Object-Relational Mapper). Yani veritabanındaki tabloları senin C# sınıflarına çeviriyor, sen de o sınıflarla oynayarak veritabanını yönetiyorsun. Kod yazmak yerine nesnelerle çalışıyorsun, ne güzel değil mi? Bu sayede veritabanı karmaşıklığı ortadan kalkıyor gibi görünüyor. Hele o migrations olayı var ya, aman aman! Veritabanı şemanı kodla yönetiyorsun, sonra bir komutla veritabanını güncelliyorsun. Kendi programım sınıfta kaldı :)) ama neyse, işte o özellik fena değil.
Fakat… Evet, büyük bir ‘ama’ var burada. EF bazen o kadar akıllı davranmaya çalışıyor ki, senin ne istediğini anlamıyor sanki. Hani bir yemeği yaparken tarifin dışına çıkmak istersin ya, ama tarifte öyle bir şey yazıyordur ki, değiştiremezsin… İşte EF’in bazı sorguları da öyle olabiliyor. Bazen en basit SQL sorgusunu bile öyle bir hale getiriyor ki, anlaması güçleşiyor. Hem performans olarak da bazen beklediğini alamayabiliyorsun. Özellikle büyük veri setleriyle uğraşırken, o generate edilen SQL kodları bazen kan ter içinde bırakabiliyor insanı.
İşte tam bu noktada Dapper devreye giriyor. Dapper, micro-ORM dediğimiz kategoriye giriyor. Yani EF kadar kapsamlı değil, ama işini süper hızlı yapıyor. Dapper ile sen SQL sorgularını kendin yazıyorsun. Evet, bildiğin SQL! Ama bu kötü bir şey değil, aksine bana göre çok daha iyi. Çünkü sen ne istediğini biliyorsun ve o sorguyu en optimize şekilde yazabiliyorsun. Dapper da senin yazdığın o SQL sorgusunu alıp, veritabanından çektiği datayı direkt senin C# sınıflarına map’liyor. Hem de inanılmaz bir hızla!
Geçenlerde bir projede, normalde EF ile 3 saniyede dönen bir rapor vardı. Sonra bunu Dapper’a çevirdim ve aynı rapor 300 milisaniyede gelmeye başladı. Aradaki farkı hayal edebiliyor musunuz? Tamamen aynı işi yapıyorlar ama birisi ışık hızında, diğeri sanki yavaş çekimde. Tabii bu her zaman böyle olmayabilir, ama genel eğilim Dapper’ın daha hızlı olduğu yönünde. Hele bir de stored procedure’lerle çalışıyorsanız, Dapper resmen hayat kurtarıcı oluyor. Direkt stored procedure’ü çağırıp, sonuçlarını alıyorsun. Ne bir karmaşıklık, ne bir performans kaybı…
Bir de şu var tabii, Dapper’da hata yapma ihtimalin daha yüksek. Çünkü sen SQL’i kendin yazıyorsun. Hani dağcılık yaparken rota seçimi çok önemli ya, yanlış bir rota seçersen hem zaman kaybedersin hem de tehlikeye girersin. Dapper da öyle. Yanlış bir SQL sorgusu yazdın mı, programın patlayabilir ya da beklediğin sonucu vermeyebilir. EF’in o güvenlik kalkanı, o senin adına düşünen yapısı burada yok. Ama işte o zaman da kendi kontrolünde olmanın verdiği bir tatmin var, değil mi?
Şimdi ben size bir örnek göstereyim. Diyelim ki bir kullanıcı listesi çekeceğiz. EF ile bu şöyle olabilir (yaklaşık olarak):
var users = _context.Users.Where(u => u.IsActive).ToList();
Bu gayet anlaşılır, değil mi? Ama arka planda EF’in ürettiği sorgu bazen bizim canımızı sıkabilir.
Şimdi aynı şeyi Dapper ile yapalım. Bakın ne kadar basit:
var sql = "SELECT * FROM Users WHERE IsActive = 1";var users = connection.Query
Gördünüz mü? Direkt SQL’i yazdım, Dapper’ı çağırdım, bitti. Hem daha anlaşılır hem de çok daha hızlı. Tabii buradaki `connection` nesnesini bir şekilde oluşturmanız gerekiyor, o da ayrı bir konu ama genel mantık bu.
Neticede, seçim sizin. Eğer projeniz çok karmaşık değilse, hızlı bir prototip geliştirmeniz gerekiyorsa, veya performans sizin için en öncelikli konuysa, Dapper harika bir seçenek olabilir. Hatta bazen EF ile yazdığınız sorguların performansını artırmak için, kritik yerlerde Dapper kullanıp hibrit bir yapı da kurabilirsiniz. Hani bazen bir işi yapmak için hem çekiç hem de tornavida lazım olur ya, işte o hesap.
Benim kişisel deneyimim ise şu yönde: Büyük, kurumsal projelerde, takım çalışması ve veritabanı şema yönetiminin ön planda olduğu yerlerde EF daha mantıklı olabiliyor. Ama daha küçük, performans odaklı veya mikroservis bazlı projelerde Dapper’ın hızı ve esnekliği beni daha çok cezbediyor. Hani geçenlerde bir kamp gezisine çıkmıştık eşimle, hava mis gibiydi. Sabah uyandığımda şöyle bir etrafa baktım, sanki o an her şeyi yapabilirmişim gibi hissettim. İşte Dapper da bana bazen o hissi veriyor, her şeyi kontrol edebiliyormuşum gibi. 🙂 Fakat tabi, kamp dönüşü arabada dönerken yorgunluk da basıyor insanı, EF’in o rahatlığı da bazen iyi geliyor yani.
Sonuç olarak, ikisinin de kendine göre avantajları ve dezavantajları var. Önemli olan sizin projenizin ihtiyaçlarına en uygun olanı seçmek. Belki de en iyisi, ikisini de öğrenip duruma göre hangisi daha uygunsa onu kullanmak. Ne dersiniz? Bu arada, eğer Dapper ile ilgili daha detaylı bilgi almak isterseniz, Google’da harika tutorial’lar bulabilirsiniz. Ya da YouTube’da karşılaştırma videoları da var, onları da izleyebilirsiniz. Ben de bazen oralara bakıyorum yeni şeyler öğrenmek için.
Umarım bu yazı size bir fikir vermiştir. Bir sonraki yazıda görüşmek üzere, kendinize iyi bakın!