ORM’de Su Bulanık
Evet, anladık: kimse artık hart hurt SQL yazmak istemiyor. Zaten sunucu tarafında karmaşık SP yazma devrini de çoktan bitirmiştik. Vaktidir o zaman yeni moda işlere girişmenin. Değil mi dostlar?
Camiadaki yeni temayül, kod üreteçler kullanmak ve ORM kütüphaneleri ile ilişkisel verileri konforlu biçimde, SQL'e bulaşmadan manipule etmek. Bu eğilim Java camiasından bizim camiaya naklolmuştur, kabul.
Yalnız bu temayül artık doruk noktasına ulaştığından olsa gerek, ortalık ORM'den geçilmiyor. Şu listeye bir bakınız:
- .NET Persistence
- BBADataObjects
- DataObjects.NET
- Data Tier Modeler for .NET
- DotNorm
- Eldorado.NET
- Enterprise Core Objects (ECO™)
- Entity Broker
- eXpress Persistent Objects for .NET
- FastObjects.NET
- JC Persistent Framework
- LLBLGen Pro
- ModelWorks
- Nhibernate
- Nolics.NET
- Norm
- Norpheme
- ObjectBroker
- ObjectSpaces
- ObjectSpark
- Objectz.NET
- OJB.NET
- OPF.Net (Object Persistent Framework)
- ORM.NET
- Pragmatier Data Tier Builder
- RapTier
- Sisyphus Persistence Framework
- TierDeveloper
- Bob.NET
- ObjectPersistor.NET
- Genome
En eskileri belki Nhibernate ama bu kalabalık, insanın üzerinde "akşam üstü İstanbul trafiği" etkisi oluşturuyor ve iyiyi-kötüyü ayırt ettirmez oluyor.
Bu kalabalık ürün listesi arasında ticari olanlar da var ama genel itibariyle açık kodlu. Açık Kod rüzgarının .NET camiasında artık esip gürlediğinin bir delili bu liste.
Ya MS cephesi?
Microsoft'un elinin armut toplamadığını tahmin edebildiniz: o da ADO.NET Entity Framework ve yepyeni bir sorgulama yapısı olarak LINQ kartlarını açtı. İşin garibi herkes çok beğeniyor MS'in yaptıklarını. Microsoft bu LINQ işini o kadar ciddiye alıyor ki, C#'ı sırf bu işe destek için güncelliyor. Son günlerde "her şey linq için".
LINQ emekleme sürümünde henüz. Performans darboğazı var. Ama koşmaya başladığında, şu yukarıdaki listenin LINQ entegrasyonu yapmaktan başka çıkar yolu görünmüyor.
Netice
- Halkın SQL'den kurtulalım çırpınışları yerindedir, desteklenmelidir.
- ORM karmaşasına (hele de ticari olanlarına) pek dalmamak lazımdır.
- "Linq to SQL" insanı cezbediyor, bir an evvel uygulamak lazımdır:
- .NET 2.0 uygulamaları öntanımlı olarak LINQ desteklemiyor ama LINQ kullanan bir kütüphaneyi kullanabilir.
- .NET 3.5'ta LINQ kullanmayanı dövüyorlar.
- Performansın kritik olduğu uygulamalara, LINQ takoz olacaktır.
Bu yazı, iş görür mü?
February 15th, 2010
Entity Framework’ü anlamaya çok çalıştım. Dediler ki “hacı database ayağını hiç düşünme, sadece domain’i düşün”. Tamam dedik o zaman açalım bi EDMX tasarlayalım modelimizi. Hop “database nerede şema lazım” diye sordu. E hani database düşünmüyorduk. Hadi “empty database” diye başlatırsak da entity=tablo olacak şekilde veritabanını birebir oluşturuyor. İyi güzel, ama o zaman veritabanı tasarlamaktan farkı ne? Aslında sadece foreign key’leri association olarak alıp biraz da lazy loading diye süslemişler. Onun dışındaki herşey bir proxy class’a gömülmüş, makarna gibi kod. Kodu ben değiştiremeyeceksem ne anladım. Paşalar gibi database’i tasarlarım, FK’leri oturturum, SP’lerimi yazarım gerektiği yerde, üzerine bir ActiveRecord pattern + partial class ile repository koyarım. On numara. Her entity modifikasyonu sonrasında veritabanımı baştan oluşturmam en azından. Artı kod benim kodum olur. Baktığım her yeri anlarım, tanırım. Dahası performans kaybetmem.