Bu kavramı kullanırken, yerine göre veri, yerine göreyse iş katmanı dediğimiz kodların bulunduğu katmandan veritabanına direkt müdahale etmeyip bu işi bir ORM yapısına (aracısına) bırakırız. Bu ORM yapısının bize sağladığı yöntemle ORM'ye istediğimizi anlatırız, veritabanı ile o ilgilenir. Özetle ORM aracısına bana şunu ver deriz, o veritabanından alır ve nesnel formata döndürüp bize verir, aynı şekilde biz ona nesnel formatta verirsek, o da veritabana anlayacağı şekilde iletir, sonucu da yorumlayıp geri döner.
Kabaca bir SQL Server tablosuna bir
SqlCommand ile SELECT sorgusu çektiğimizde ID (int) ve Name (nvarchar) alanlarından oluşan bir tablo verisi dönüyorsa, biz kodumuzda bir sınıf hazırlayıp ID (int) ve Name (string) diye iki property ekleriz. Daha sonra bir DataReader ile kayıtlarda dönmeye başlarız ve her kayıt için bu hazırladığımız sınıfın bir örneğini yaratıp ilgili alanın verisini ilgili property'lere set ederiz. Böylece gelen veriyi oluşturduğumuz sınıfa maplemiş oluruz. İşte ORM'nin M'sindeki Mapping'in anlamı budur. Aynı şekilde bu alanları değiştirip kayıt güncelleme yaparken de ilgili alanlar veritabanında güncelleniyor. Bu sınıfın örneği olan nesnelere de terminolojide Entity diyoruz. Bu tarz bir yapı kurduğun zaman ORM kullanmış oluyoruz. ORM'nin O'su da bu entity dediğimiz nesneler oluyor.Bu anlattığımız transfer işlemleri sırasında veritabanı ile olan bağlantılarda veritabanına gönderilecek olan komutların hazırlanması ve nesnelerin özelleklerinin değerlerini veritabanına gönderecek olan işlem bir hayli zor bir süreçtir. Bu yüzden bir çok girişim bu yapıyı basitleştirmek ve otomatize etmek için kendi Tool'larını piyasaya sürmüştür.
Bunlara örnek olarak Microsoft'un desteklediği ücretsiz Entity Framework ve LinqToSql, açık kaynak olarak geliştirilen NHibernate, Telerik firmasının geliştirdiği ücretli OpenAccess gibi birçok araç piyasada bulunmaktadır. Bu tarz araçlarla ORM mimarisinde uygulama geliştirmek mümkündür, tek yapılması gereken onları kullanmayı öğrenmek için zaman harcamak.
Piyasadaki bu araçlar genel ihtiyaçları çok büyük ölçüde karşılasa da yetersiz kaldığı noktalar olabilir. Veya çözümü vardır ama bir türlü bulamayız. Bunun dışında bizden kaynaklanmayan bug'lar veya implementasyon eksiklikleri olabilir. Örneğin ücretli satılan bir ORM Tool, Oracle implementasyonunda hala birçok eksiklik barındırmaktadır. Ayrıca kapalı sistemler olduğundan dışarıdan pek müdahale edemeyiz. Bir işlem yapılırken kendi içinde belki hiç ihtiyacımız olmayan gereksiz işleri yapar ve performansı düşürür. Programlanabilirlik desteği varsa bunu modifiye edebiliriz ancak bu da başlı başına yeni ülke keşfetmek gibi birşeydir.
Temelde tüm ORM toollarında tablo ile direk olarak iletişime geçildiğinden dinamik SQL oluşturma süreci vardır. Örneğin LinqToSql bu sorguları Linq Expression'ları SQL sorgusuna çevirerek üretir. Ya da başka durumlarda nesnelerin durumuna göre oluşturulur. Ancak bu SQL'i nasıl oluşturacağına biz değil tool karar verir. Bazen onun vereceği karar, veri yapısından dolayı performansın düşmesine neden olabilir.
İşte böyle durumlarda bu ORM aracını kendimiz hazırlamak isteyebiliriz. Yani o maplenecek olan sınıfları işleyip gerekli SQL sorgularını üretip veritabanına gönderecek veya oradan çekince classlara map'leyecek olan yapıyı kendimiz oluşturmak isteyebiliriz. Böylece her adımı kendimiz kontrol etmiş oluruz. İstediğimiz özelliği katar, istemediğimizi katmayız. Ancak bu karar çok politik bir karardır. Çünkü ORM'ler genellikle tüm ihtiyaçları karşılar. Ancak belli bir seviyeye gelmiş, kompleks işler yapan yazılımcılar bunu düşünebilir, zaten bu ihtiyaç ancak o zaman hissedilmeye başlar.
Hiç yorum yok:
Yorum Gönder