Makale Özeti

Bu makale Object/Relational Mapping deyiminin ne olduğundan, ve devamında açık kodlu bir Object/Relational Mapping aracı olan NHibernate'den bahsetmektedir.

Makale

nh1

Object/Relational Mapping ve NHibernate

Bu makale Object/Relational Mapping deyiminin ne olduğundan, ve devamında açık kodlu bir Object/Relational Mapping aracı olan NHibernate'den bahsetmektedir.

Verinin Saklanması gereksinimi

Hemen hemen her uygulama veri saklar, yani uygulamalar açıldığında bazı verileri kullanıcılardan girdi olarak alır ve uygulama daha sonra tekrar açıldığında bu verileri bir şekilde kullanır. Veriyi sadece uygulama açık kaldığı sürece hafıza saklansaydı uygulama bir şekilde kapanıp tekrar açıldığında, uygulama verileri kaybetmiş olurdu.

Günümüzde ise veriyi saklamak dendiğinde ilişkisel veritabanı yönetim sistemleri (RDBMS) akla gelmektedir. SQL Server, Oracle gibi veritabanı yönetim sistemleri verinin kaydedilmesi, ve daha sonra tekrar erişilmesi işlemleri için sağladıkları yüksek performans sebebi ile tercih edilen ürünlerden bazılarıdır.

.Net uygulamalarında da veri saklamak dendiğinde akla gelen verinin SQL Server üzerinde saklanması olmaktadır.

.Net ile uygulama geliştirirken veritabanında verilerin saklanması için ADO.NET kullanılır ve bu işlem kurumsal bir uygulama için vazgeçilmezdir zira uygulamanın amacı veridir. Visual Studio editörünün kolaylıkları ve ADO.NET'in gelişmiş özellikleri sayesinde sürükle bırak ile dahi temel fonskiyonlara sağlanabilmektedir. Ancak sürükle bırak gibi işlevler büyük çaplı uygulamalarda muhakkak ki yetersiz kalmaktadır, katmanlı ve mümkün mertebe soyutlanmış bir yapı ile uygulamanın mimarisi sağlam temellere dayandırılmaya çalışılır. Tabi burada veri ekle, güncelle,sil, sorgula gibi temel CRUD (create,read,update,delete) işlevlerini yazmak uygulama geliştirici için hem sıkıcı olmaktadır, hem de zaman kaybı demektir. Ayrıca uygulamanın tasarımı için başarısı kanıtlanmış yöntemler uygulanmaya çalışılmaktadır.

Uygulama geliştiriciler ise veri erişim katmanı için hızlı ve başarılı bazı araçlar veya yöntemler uygulamaya çalışırlar. Örneğin tekrar eden işlerden kurtulabilmek için CodeSmith1 gibi araçlar ile kalıplar oluşturulup kod üretilmesi sağlanabilir.

Verinin temsili

Kurumsal iş uygulamalarında verinin nasıl temsil edileceği, katmanlar arasında nasıl transfer edileceği önemlidir. Hızlı biçimde üretilecek ve çalışır hale geldikten sonra bir daha üzerinde düzenlemeler yapılmayacak, yeni versiyonları çıkarılmayacak büyük çaplı olmayan bir uygulama için sunum ve veri katmanından oluşan bir yapı sorun çıkarmayabilir. Sunum katmanı doğrudan veri tabanından haberdar olabilir. Ancak büyük ölçekli kurumsal bir uygulamada katmanlı ve object oriented bir yaklaşım izlenmelidir.

Ayrıca verinin nasıl temsil edileceği sorusuna DataSet dendiğinde bir çok kişi bunu object oriented bir mimariye uygun bulmaz. DataSet bir object'tir ancak bir Domain Object değildir. Veritabanındaki tablolar hakkında bilgi içeren ve verileri tutan bir yapıdır. Dataset'e bir veri havuzu denebilir, aslında ilişkisel veritabanı sistemindeki verinin aynı yapı ile hafızada temsilini sağlayan bir veri kaynağıdır. Yani Musteri ve DataSet aynı şey değildir. DataSet bir domain modelinizdeki bir kalem değil, kalemleri içinde tutan bir kap olarak tanımlanabilir.

Uygulamanın analiz safhasında iken yapılan görüşemelerde "Müşteriler sisteme girer ve istediği Ürünleri seçip Sipariş verirler." gibi bir cümle kuruyorsak. Bu cümledeki nesneleri bulup bunları uygulamamızda da kullanırız. Bu cümle ışığında anlıyoruz ki uygulamamızda Musteri,Urun ve Siparis adında üç nesne olacak. Özetle çok katmanlı kurumsal iş uygulamalarında verinin temsili için -domain object diye tanımlanan- gerçek nesneler kullanılır.

Peki veriyi nesneler ile temsil etmek zorunlu mudur? Aksi olmaz mı?  Kesinlikle bu zorunlu değildir. Zaten her zaman doğru olan bir yol olmadığı dünyaca ünlü uzmanlarca da kabul edilmiş bir gerçektir. Uygulamaların büyük ölçekli kurumsal uygulamalar olması ve buna bağlı olarak yoğun iş kuralı ihtiyaçları içermesi durumunda bu şekilde bir mimari kullanılması elzem olmaktadır ancak tasarım kalıbı oluşturucusu bir çok kişininde kabul ettiği gibi domain model tasarlamak büyük ölçekli kurumsal uygulamalarda gereklilik halini almaktadır.

Farklı iki ortam

İki ortam (uygulama geliştirme platformu ve veritabanı yönetim sistemleri) karşılaştırıldığın da aralarında temel bir fark vardır. Bir tarafta nesneler bir tarafta ise tablolar vardır. Veritabanı yönetim sistemlerinin veri erişimindeki avantajlarından faydalanabilmek için normalization denilen kurallara uyularak verileri saklamak için tasarlanmış tablolar vardır ancak gerçek hayattaki kesitlerini uygulamaya yansıttığımız nesneler öyle değildir. Bu iki ortam arasında bir senkronizasyon olmalıdır veri uygulama içerisinde iken tasarlanan nesnelere yüklenmeli ve o şekilde veri temsil edilmelidir. Veri saklanmak istendiğinde ise veritabanında saklanacağı uygun biçimde kaydedilmelidir.

Uygulamada kullanılan nesneleri olduğu gibi yani nesne olarak saklamak için object database sistemleri bulunmaktadır. Örneğin db4o gibi. Ancak bu sistemlerin güvenirliği henüz istenilen seviyede olmadığı için ilişkisel veritabanı yönetim sistemleri temel tercih olmaktadır.

Object/Relational Mapping

Object/Relational Mapping (bundan sonra O/RM yazacağım) ilişkisel veritabanı sistemlerinde bulunan tablolar,viewlar ile uygulama tarafında bulunan nesnelerin ilişkilendirilmesi (map'lenmesi) işlemine verilen genel bir terimdir. O/RM bir araç değildir. O/RM için belirli bir araç kullanmak zorunlu değildir. Kendimiz O/RM frameworkümüzü oluşturabiliriz. Ancak başarısı kanıtlanmış yöntemler takip edilerek hazırlanmış (kabul edilmiş tasarım kalıpları uygulanarak), bir çok nokta düşünülürek tasarlanmış ve yeterli esnekliğe sahip araçlar kullanılmak üzere beklerken, esas işimiz yerine esnek bir O/RM alt yapısı oluşturmaya kalkışmak vakit kaybı olacaktır.

Object/Relational Mapping araçlarının çok katmanlı mimarideki yeri persistence layer  olarak gösterilmiş olan, veri erişim katmanı olarak da isimlendirilebilen katmandır.

O/RM alt yapısı bizim için ne yapar?

O/RM araçları kendi alt yapılarında tasarlandığı şekilde hazırlanmış olan mapping yapılandırmasına göre illişkisel veritabanı yönetim sisteminde yer alan tablolar ile bunlara karşılık gelen uygulama içindeki domain objectler arasında veri aktarımını sağlar. Yani verileri çekip nesnelere yüklemek için herhangi bir ado.net kodu veya sql sorgusu uygulama geliştirici tarafından yazılmaz. Tanımlanan mapping tablosuna göre gerekli sql sorgusu O/RM framework tarafından oluşturulur, dönen veriler nesnelerin propertylerine yüklenir ve uygulama içinde veriyi temsil edecek halini alması sağlanır.

Nesneleri saklanması, nesnelere ulaşılması, silinmesi, güncellenmesi gibi işlemler için alt yapıda tanımlanmış olan veritabanı yönetim sisteminin anlayacağı dilde sql sorgusunu oluşturulması ve işletilmesi tamamen O/RM framework'ünün işidir. Bir çok O/RM framework'ü farklı veritabanı yönetim sistemlerini desteklemektedir. Örneğin Oracle ile çalışan bir uygulamayı SQL Server'a aktarmak (yada tam tersi) gibi bir senaryo için genellikle yapılması gereken ufak bir tanımlamanın değiştirilmesinden ibarettir.

O/RM araçları nesnelere erişmek için kendi nesne modellerinde tanımlanmış metodlar sunmaktadır. Bir çok O/RM aracı metodlar ile sunulan genel yapıların yanında daha özel ve karmaşık işlerde kullanmak için object query olarak tabir edilen kendi sorgulama dillerine de sahiptir.

O/RM araçları

O/RM araçlarından en bilinen ve tabiki başarılı olanları NHibernate, LLBLGen Pro gibi araçlardır. Piyasadaki tüm .NET O/RM araçlarının listesi için sharptoolbox.com adresine bakabilirsiniz.

NHibernate ?

Bu araçlarndan NHibernate açık kaynak kodludur. Java dünyasında kullanılan Hibernate (N yok!) in .NET için dönüştürülmesi olarak devam eden bir projedir. Güncel sürümü 1.0.1 dir. Hibernate in 2.1 sürümünde olan özellikleri içerir. Hibernate'in 3.1 sürümündeki özelliklerin dönüştürülerek NHibernate'e kazandırılması için NHibernate'in geliştiricileri çalışmalarına devam ediyorlar. Hibernate'i java dünyasında destekleyen firma olan JBoss firması NHibernate'i geliştiren ekibin başındaki kişi kendi bünyesine katarak NHibernate'i de resmi olarak desteklemeye başladı.

Microsoft'un bir O/RM çözümü yok mu? Microsoft .NET 2.0 ile ObjectSpaces adında bir O/RM duyurmuştu. .NET 2.0'ın beta sürümlerinde ObjectSpaces yer alıyordu. Ancak Microsoft daha sonra yaptığı bir açıklama ile ObjectSpaces'ı .NET 2.0 içinen çıkardı. ObjectSpaces'in .NET 2.0 release olduktan daha sonra ek paket olarak çıkacağı duyurulmuştu. Şu an da LINQ adındaki .NET 'in sonraki sürümünde yer alaması beklenen yeni bir teknoloji üzerinden çalışıyorlar. LINQ nun bir ayağı ise; DLINQ. DLINQ'in .NET Framework içerisindeki O/RM çözümü olması bekleniyor. Ancak bir süre daha Microsoft kaynaklı bir O/RM çözümümüz yok.

NHibernate'i nhibernate.org adresinden indirebilirsiniz. NHibernate açık kaynak kodlu bir yazılımdır, kaynak kod veritabanı internet üzerinden erişilebilir durumdadır. Site üzerinde download bölümünden indirilebilen güncel sürüm yanında sürekli güncellenen kaynak kod veritabanından son güncellemeleri ve düzenlemeleri içeren kaynak kodlar cvs aracılığı indirilebilmektedir.

Object/Relational Mapping ve NHibernate hakkında genel bilgi vermek istediğimiz bu makalemizin ardından NHibernate ile uygulama geliştirme makaleleri ile devam edeceğiz.

Cengiz HAN
Microsoft ASP.NET MVP
cengiz@cengizhan.com

Not: Makalemizin temel konusu Object/Relational Mapping'den bahsetmek ve NHibernate'i tanımaktır. Eğer domain object ve dataset arasında karar verememiş iseniz sizi MSDN'deki bir makaleye yönlendirmek istiyorum. Introducing Custom Entity Classes.

1 CodeSmith ile ilgili makale serimin ilki için tıklayınız.