ORM Yapıları, Eksi ve Artıları

ORM Yapıları

ORM Nedir? Ne İşe Yarar?

ORM yapılarını sanırım bir çoğumuz duymuşuzdur. Object Relational Mapping-İlişkisel Nesne Eşleştirme’nin kısaltılmışı olarak biz developer’ların hayatına çok çok uzun olmayan bir zaman önce giren ve işlerimizi gerçek anlamda kolaylaştırmaya dönük yapılar.

Eskiden hatırlayın; bir kayıt üzerinde işlem yapmak ve/veya binlerce kayıt üzerinde işlem yapmak için satırlarca SQL komutu girmek zorundaydık.
İşte, bir birinden farklı bir çok ORM yapısı ile bu sorgular çok ama çok kısalmış durumda artık.

Peki bu işlemlerin kısalması kadar, hayatımıza etki eden görece “zararlı” sayabileceğimiz yanları yok mu?
Elbette yer yer ortaya çıkabilmekte. Bunların en başında da PERFORMANS faktörü geliyor.

Aslına bakarsanız düz mantıkla değerlendirecek olursak ORM yapıları, sizin SQL sorgularınızı kendi methodlarıyla oluşturmanızı sağlayarak, arka planda yine SQL’in anlayacağı cümleciklerle bunu DB’nize anlatıyorlar ve bu sayede sizin bir ton SQL cümleciği yazmaktan kurtulmanızı sağlıyorlar.

Ve aslında en önemli etkenlerinden bir tanesi de; Kullandığınız ORM’nin özelliğine bağlı olarak, kodlama tarafında hiçbir değişiklik yapmadan, MySQL=>MSSQL veya benzeri (ORM’nizle ilişkisel) tüm veritabanları arasında sadece connector değiştirerek geçiş yapabilmenize olanak sağlayabilmeleri.

ORM Kullanmanın Artıları

ORM kullanıyor olmanız, yukarıda da bahsettiğimiz gibi kod kısmında hiçbir değişiklik yapmadan kullandığınız ORM’nin desteklediği DB yapıları arasında geçiş yapabilmenize olanak sağlayabilir.

Bunun yanı sıra, yine en büyük artılarından bir tanesi de kod tarafından sql cümlecikleri yazmaktan sizi kurtarıyor olmalarıdır.

Aynı zamanda tüm field’lar ilgili property’lere atandığından, kodlamada bu alanları da çok ama çok rahat bir şekilde kullanabiliyor olmanız, yani kısacası ciddi bir yazım kolaylığı sağlıyor olmaları.

ORM Kullanmanın Eksileri

Aslında bu başlığı bu şekilde kullanmak ne kadar doğru bilemedim. Çünkü kullandığınız ORM’ye ve ondan beklediğiniz performansa göre ORM’nin eksisi kullanılan ORM’ye göre değişkenlik göstermektedir. Ama belki de genel olarak söz edebileceğimiz tek eksi ADO.Net ile kurgulanmış bir projeyi (tabii ki DB mimarisinin de iyi olduğunu ön görerek) ORM kullanarak ilerlediğinizde kısmi performans problemleriyle karşılaşabilmektesiniz. İşte tam da bu noktada hangi ORM’yi kullandığınız ve bunları mümkünse kendi mimariniz üzerinde belli testlere tabi tutarak seçmeniz ciddi önem arz ediyor.

Kimi ORM’ler select işlemlerini ADO.Net’e çok ama çok yakın performansta yapabilirken, kimileri ise Select işleminde çuvallayarak, (hız anlamında) insert, update, vb… işlemleri gerçekten ADO.Net’e çok ama çok yakın sürelerde yapabilmektedir.

İşte tam da bu noktada sizin seçiminiz ve yapmış olduğunuz testler ciddi önem arz etmektedir.

Peki ADO.Net Vazgeçilmez Mi?

Kimilerine göre bu sorunun yanıtı evet iken, ben ve benim gibi düşünenler için ise bu sorunun cevabı kısmen evet şeklindedir. Çünkü günümüz dünyasında bir çok işyerinde hızlı ve “kusursuz” yazılımlar istendiği için ORM yapıları bu noktada biz developerların işlerini ciddi anlamda rahatlatmaktadır. Bu nedenle de kendi yapınıza en yakın gördüğünüz ORM’yi kullanmak faydalıdır.

Şüphesiz yapılan bir çok test var ve bu testlerde hiçbir DB işlemi ADO.Net’in önüne geçebilmiş değil. Ancak onunla kafa kafaya giden ORM’ler de yok değil. Hal böyleyken ORM kullanmakta hiç mantıksız olmasa gerek. Tabi takıldığımız, tıkandığımız ve ekstra performans gerektiren yerlerde de her ORM’de aktif olarak kullanabileceğiniz kurtarıcı StoredProcedur’lerimiz olduğunu unutmayalım.

ORM’ler arasındaki kendi nacizane testlerimi de yine bugün yayınlamayı düşündüğüm ikinci yazımda anlatıyor olacağım.

Şimdiden herkese iyi çalışmalar…

Share this Story

Related Posts

Kimler Neler Demiş?

avatar
  Subscribe  
Bildir

Search