Yeni Nesil Veri Programlama Modeli (ADO.NET 3.5)

Microsoft firması .NET Framework 3.0 ile birlikte ADO.NET’in yeni bir versiyonunu yayınlamadı. .NET Framework 3.5 ile birlikte yeni eklentiler kazandırılmış ADO.NET 3.5 sürümü yayınlandı.
Microsoft, ADO.NET 3.5 sürümleriyle birlikte veritabanı uygulama mimarisinde büyük kolaylık sağlayan Object Relational Mapping (O/R Mapping) yöntemini destekleyecek önemli adımlar attı. Bu amaçla ADO.NET Entity Framework aracı geliştirildi. Konunun ayrıntılarına geçmeden önce bu kavramları tanımlayalım ve neden yeni bir yaklaşıma ihtiyaç duyulduğunu açıklayalım.
Günümüzde özellikle veritabanına dayalı uygulamalar, katmanlı mimari (multi-tier architecture) üzerine kurulur. Bu konsept dahilinde uygulamalar, veri (data), iş (business logic) ve sunum (presentation) olmak üç temel katmandan oluşur. Tasarım sürecinde ilk sırada bulunan veri katmanı oluşturulurken çeşitli veri modelleri kullanılır. “Verileri mantıksal düzeyde düzenlemek için kullanılan kavramlar, yapılar ve işlemler bütününe veri modeli denir.
70’lı yıllardan bu yana Veritabanı Yönetim Sistemleri’nin (Database Management System – DBMS [VTYS]) değişmesiyle birlikte çeşitli veri modelleri geliştirildi:

  • Sıradüzensel veri modeli (Hierarchical data model)
  • Ağ veri modeli (Network data model)
  • İlişkisel veri modeli (Relational data model)
  • Nesneye yönelik veri modeli (Object oriented data model)

Her VTYS’nin kendine özgü veri modeli bulunur. Veri modeli kullanılarak veritabanının kavramsal ve dış şemaları oluşturulur. Burada bu modellerle ilgili kavramları tanımlayacağız ve VTYS’den bağımsız tasarım yapmamızı sağlayan ER modelini ayrıntılı ele elacağız.
Entity Relationship (ER) Modeling
Günümüzde bir veritabanı uygulamasının başarılı olmasını sağlayacak ilk parametre, iyi bir veritabanı tasarımına sahip olmasıdır. Bir uygulama geliştirileceği zaman öncelikle bu uygulamanın ne tür bir uygulama olduğu ve ne tür verileri içereceği belirlenir. Veritabanı tasarımı, bu soruların yanıtları doğrultusunda şekillenir. İlişkisel veritabanı sistemlerinde veritabanı tasarımının ilk adımı veri modellemedir.
Veri modelleme, veritabanı verilerinin ve bunların arasındaki ilişkinin organizasyon içindeki herkesin rahatlıkla anlayabileceği metin ve şekillerle ifade edilmesidir. Bilindiği gibi organizasyon içindeki kullanıcı, tasarımcı ve programcı gibi teknik veya teknik olmayan kişilerin veriye bakış açıları ve veriyi tanımlamaları farklılık arzeder. Hazırlanacak olan veritabanı tasarımında bu kişilerin hepsinin rolü olduğu için bu kişiler arasında ortak bir dil oluşturmak gerekir. Bu dilin temeli hiç şüphesiz gerçek dünya varlıklarıdır. Veritabanını kullanacak olan kullanıcı, tasarlayacak olan tasarımcı ve kodlayacak programcı ihtiyacını ancak gerçek varlıklar (nesneler) üzerinden daha kolay anlatabilir. Fakat gerçek dünyada varlıklar daha karmaşık özellik ve yeteneklere sahip olduğu için bu varlıklar üzerinden ifade edilmiş yapıyı, veri modellemesi aracılığıyla daha anlaşılır hale getirmek gerekir. Buradaki amaç, organizasyon içindeki herkesin gördüğü zaman kolaylıkla anlayabileceği ve veritabanı yapısını gözünde canlandırabileceği bir veri modeli çıkarmak ve bu model üzerinden organizasyon ihtiyaçlarını doğru şekilde karşılayacak fiziksel bir veritabanı tasarımına zemin hazırlamaktır.
Veritabanı modellemenin üç türü vardır. Bu türler aynı zamanda veritabanı model veya tasarımın aşamalarını da bildirir.
Kavramsal tasarım (Conceptual design): Veri tabanının hangi verileri içereceğinin ve bu veriler arasındaki ilişkilerin belirlendiği aşamadır. Bu aşamanın en önemli özelliği veritabanı nesneleri herhangi bir VTYS şemasına bağlı kalınmadan modellenir. Bu aşamada organizasyon içindeki herkes aktif olabilir. Kavramsal modelleme, mantıksal modellemenin çözümlenmesini ve tasarımını kolaylaştırmak için atılmış bir adımdır.
Mantıksal tasarım (Logical design): VTYS’nin tanımlandığı aşamadır. Kavramsal tasarımda modellenen yapı, karar verilmiş olan VTYS’ye uygun şemaya dönüştürülür. Veritabanında kullanılacak veri türleri, tablo üzerindeki anahlarlar, tablo satırlarının birbirleriyle ilişkileri bu aşamada belirlenir. Bu aşamada daha çok tasarımcı ve programcı rol oynar.
Fiziksel tasarım (Physical design): Verilerin hangi disk veya başka fiziksel depolama sistemlerinde nasıl tutulacağı, ne tür işlemci yapılarının kullanılacağı, aygıtların verilere hangi yol ve kurallar dahilinde ulaşacağı ve bunların doğrultusunda VTYS yazılımın hangi işletim sistemi üzerinde koşacağı belirlenir. Daha çok veritabanı programcısının aktif rol oynadığı bu aşamada oraya çıkan modelin daha önce organizasyon elemanlarıyla birlikte karar verilmiş olan kavramsal ve mantıksal modelle olan uyumluluğu test edilir. Kısaca, kavramsal ve mantıksal tasarım aşamasında, veritabanı şemasına karar verildiğini, fiziksel tasarım aşamasında da veritabanının fiziksel yapısına karar verildiğini söyleyebiliriz.
Bu aşamalardan sonraki süreç, uygulama programının yazılarak kullanıcıların belirlenmiş yetkiler ölçüsünde veriye ulaşmasıdır.
Kendisi soyut bir yapı olan veri modeli, ANSI-SPARC mimarisine göre kavramsal (conceptual), dış (external) ve iç (internal) olmak üzere üç seviyeli soyutlama derecesine sahiptir. Bu seviyeler, veri ortamının organizasyon içindeki kişiler tarafından görünen görünümü temsil eder. Dış seviye, veritabanının kullanıcıya olan görüntüsü ifade eder. Her kullanıcının özgül bakışı ve bilgisi doğrultusunda birçok dış görünüm oluşturulabilir. Bu görünümler kullanıcı programları veya doğrudan SQL cümleleriyle oluşturulur. Daha çok veritabanı sahiplerinin hazırladığı ve veritabanının üst düzeyde soyutlanmış hali olan kavramsal seviye, veritabanının kuş bakışı görüntüsünü temsil eder. Bu seviyede veritabanında hangi verilerin saklandığı ve bu veriler arasındaki ilişki görünür. Kavramsal modelde veritabanı yazılım ve donanımla ilgili bilgi bulunmaz yani VTYS’den bağımsız bir görüntü sunar. İç seviye ise VTYS’ye bağımlı olup veritabanının VTYS’ye göre hazırlanmış şemasını belirtir. Veritabanının en alt düzeyde soyutlanmış olan bu seviyede verilerin veritabanın nasıl saklandığı ifade edilir. Aynı zamanda fiziksel seviye olarak ta bilinir.
Veritabanı tasarımı konusunda bu kadar giriş yapmamız yeterli olacaktır. Asıl konumuz; kavramsal tasarım aşamasında en çok kullanılan yöntem olan Varlık-İlişki (Entity-Relationship, ER) modelidir. ER modeli, kavramsal veri modelini herhangi bir VTYS şemasına bağlı kalmadan ana hatlarıyla ER diyagramı üzerinde şematik olarak gösterme tekniğidir. Bu teknik, organizasyon içerisindeki teknik veya teknik olmayan kişiler arasında verinin farklı görünümlerini ortak bir kalıba dönüştürür ve veritabanı uygulamalarının daha kolay geliştirilmesini sağlar. ER çizenekleri için, genellikle UML gösterimleri kullanılır.
ER yönteminin çıkış amacı tasarımcıların oluşturduğu nesne modelini, nesne kavramını anlamayan ilişkisel veritabanı yönetim sistemlerine kolaylıkla uyarlayabilmektir.
ER modeli, teknik olarak varlıklar (entities) ve ilişkiler (relationships) koleksiyonundan oluşur. ER modelinin temelinde bu bölümün de anahtar kelimesi olan varlık bileşeni bulunur. Varlık ifadesi, Yazılım Mühendisliği literatüründe gerçek dünyadaki anlamıyla kullanılır. Yani soyut veya somut olarak var olan ve benzerlerinden ayırt edilebilen her şeye varlık denilir. Örneğin gerçek dünyada insanoğlu, araba, devlet nesneleri varlık olarak nitelendirildiği gibi nesne tabanlı programlamada sınıflar, veritabanı yönetim sisteminde de tablolar varlık olarak nitelendirilir. Her varlık, kendisini diğer varlıklardan ayırteden öznitelik (attribute) olarak bilinen karakteristiklere sahiptir. Veritabanındaki tablolar, satır ve sütunlardan oluşur. Tablo satırlarının her biri bir tek varlığı temsil eder. Varlığın her bir niteliği bir sütunda temsil edilir. Örneğin bir elektronik ticaret projesinde “Musteri” bir varlık, müşterinin “AdSoyad” bilgisi, bu varlığa ait bir nitelik olarak tanımlanabilir. “AdSoyad” bilgisinin “Murat Şensoy” olarak belirlenmesi bu niteliğin değeridir (data value). Özniteliğin alabileceği veya aldığı değerler etki alanı (domain) olarak tanımlanır.
VTYS’ler varlık kümesi ve onların arasındaki etkileşimden oluşur. Varlıklar arasındaki etkileşim, varlık ilişkisi olarak tanımlanır. Varlıklar arasında üç tür ilişki kurulur:
Birden çoğa ilişki (one-to-many relationship): Bir tablonun bir kaydına karşılık ikinci tabloda birden fazla kaydın olmasıdır. “Siparis” ve “Musteri” tabloları arasındaki ilişkidir. Bir sipariş, sadece bir müşteriye ait olabilir fakat bir müşterinin birden fazla siparişi olabilir. Bu ilişki 1:M ile temsil edilir.
Çoktan çoğa ilişki (many-to-many relationship): Bir tablonun birden fazla kaydı, diğer tablonun birden fazla kaydıyla ilişkilidir. M:N ile temsil edilen bu ilişki genellikle üçüncü bir tablo üzerinde oluşturulur. “Ogrenci” ve “Kurs” tablolarını örnek olarak verebiliriz. Bir öğrenci birden fazla kursa katılabilir aynı şekilde bir kursa birden fazla öğrenci katılabilir. Bu ilişki “OgrenciKurs” tablosunda tutulur.
Birden bire ilişki (one-to-one relationship): Bir müşterinin bir şifresi var ve her bir şifre bir müşteriye aittir. Bu durum, bir tablo ilişkisinden ziyade ikinci tablonun birinci tablonun uzantısı olmasıdır.
Tasarım aşamasında varlık ve onlara ait öznitelikler belirlendikten sonra varlıklar arasındaki ilişkiler belirlenir ve öğe ilişki çizeneği çıkarılır (entity relationship diagramming – öğe ilişki çizeneği). Bu çizelgede veritabanı varlıkları, varlıkların türleri, varlıklar arası ilişkiler ve ilişki kuralları gösterilir. ER diyagramı hazırlayabilmek için Microsoft Visio, Sybase Power Designer gibi araçlar kullanılır. Aşağıdaki çizelgede üç tablonun yapısı ve ilişkileri gösterilmiştir.

Sonuç olarak ER tekniğinin, veritabanı oluşturulmadan önce veritabanı tasarımını kolaylaştırmak amacıyla veritabanının hangi varlıklardan oluştuğunu ve bu varlıkların nasıl ilişkilendirildiğini çeşitli şemalarla belirtme yöntemi olduğunu söyleyebiliriz. ER modelinin en önemli özelliği bu mantıksal tasarımı VTYS şemasına bağlı kalınmadan yapmasıdır.
VTYS tarafında, tasarımcılar tarafından oluşturulmuş olan nesne modelini VTYS’de saklamak için aracı olarak ER modelini kullanıyoruz. Bu ek işlem, şu anki VTYS’lerin nesne yönelimli (Object Oriented) olmamasından kaynaklanmaktadır. Aynı sorun kullanıcılarla veritabanı arasında iletişim sağlayacak veritabanı uygulamaları yazılırken de yaşanır. Özellikle nesne yönelimli bir programlama dili kullanıldığı zaman class, inheritance, property, method gibi OOP varlıkları VTYS tarafından desteklenmediği için iş katmanında OOP ve ilişkisel veritabanı özellikleri iç içe kullanılır. Uygulamaların iş katmanındaki bu iş yükünü azaltmak amacıyla O/R Mapping isimli nesne-ilişki eşleştirme yöntemi kullanılır.
Nesne-İlişkili Haritalama (Object-Relational Mapping – O/R Mapping)
Günümüzde en çok kullanılan veri modeli, ilişkisel veri modelidir. Aynı şekilde uygulamaların iş katmanı yazılırken en çok nesne odaklı programlama modeli tercih edilir. Uzun yıllardır kullanılan bu iki yöntem, uygulama geliştiriciler için ciddi kolaylıklar sağlamıştır. Bununla birlikte bu iki yöntemin kullanıldığı geniş çaplı kurumsal uygulamaların en önemli sorunu, bu uygulamaların tasarım ve geliştirme süreçlerinin yönetimi zor ve zaman alıcı bir hal almasıdır. Özellikle iş katmanında veritabanı sorgulama işlemlerinde yoğun bir şekilde SQL dilinin kullanılıyor olması ve uygulama kodlarının veritabanı şemasına bağlı kalması, uygulama geliştiricilerinin veritabanı tarafında çok zamanını almaktadır. Veritabanında yeni bir kolon ekleme, kolon değiştirme gibi tablonun şemasının değişmesi durumunda uygulamanın iş katmanındaki veri erişim kodlarının yeniden gözden geçirilmesi gerekir. Bir veritabanı uygulamasında, kodun üçte birinin veri erişimiyle ilgili olduğunu göz önünde bulundurduğumuzda veri erişim katmanında her modül için sorgulama, ekleme, güncelleme, silme gibi işlemleri yeniden kodlamak birçok yazılım mühendisi için sıkıcı ve zaman alıcı olabilmektedir.
Ayrıca iş katmanında nesne odaklı programlama tercih edildiği halde veriye nesnesel olmayan yöntemlerle erişilir. Yani veritabanında veri tutmaya yarayan tabloları, uygulama geliştirme tarafında gerçek varlıkları temsil etmek için kullandığımız nesnelerle ifade edememekteyiz. Aynı şekilde uygulama tarafında oluşturulmuş bir nesneyi de veritabanı tarafında uygun bir şekilde temsil edememekteyiz. Bu işlemleri yapabilmek için diğer veri modeli olan ve gerçek dünyayı daha iyi modelleyebilecek “nesneye yönelik veri modeli”nin gelişmiş olması lazım. Şu ana kadar bu modeli desteklemek amacıyla Nesne Yönelimli VTYS (Object Oriented DBMS – OODBMS) üzerinde çalışmalar yapılmışsa da ciddi sonuçlar elde edilemedi. Bu yüzden sözkonusu sorunları aşmak için şimdilik yapabileceğimiz ancak yöntemin iyileştirilmesi olacaktır. Bu amaçla ilişkisel veritabanı ile nesneler arasında bağlantı kurma ve eşleştirme yapma yöntemi olarak bilinen Nesne/İlişkisel Eşleme (O/R Mapping-ORM) modeli kullanılır. Bu model, uygulamaların iş katmanında kod yazımını kısaltarak veritabanı işlemlerinin daha kısa sürede geliştirilmesini, veritabanı işlemlerinde OOP yeteneklerinin kullanılmasını sağlar ve sonuçta yazılım bakımını kolaylaştırır. Bu cümleleri biraz daha detaylandıralım.
ORM yöntemi, en çok tercih ettiğimiz nesne odaklı programlama modeli ile ilişkisel veritabanı modeli arasında ilişki kurup ilişkisel veritabanındaki öğelerin, nesne odaklı dildeki nesnelere nasıl karşılık geleceğini yönetir. Tabloları sınıflara (class), satırları nesnelere (instance), kolonları bu nesnelerin özniteliklerine (attribute) bağlar, oluşturulan sınıf yordamları, tablo seviyesinde, nesne yordamları da satır seviyesinde işlemler yapmak için kullanılır. Böylece verileri sorgularken, güncellerken, eklerken, silerken nesnesel ifadeler kullanmamıza olanak tanır. VTYS tarafındaki öğelere karşılık gelen uygulama nesnelerine alan nesnesi (domain object) denilir. Bu kalıcı sınıflar, uygulama tarafında, veri erişim katmanı (persistence layer) olarak isimlendirilen alanda yaşar.
Bir anlamda uygulamayı, veritabanından soyutlamış olan ORM yaklaşımı, veri işleme katmanını daha hızlı oluşturmamızı, veritabanı işlemlerinde daha az SQL kodu yazmamızı ama bununla birlikte verileri en az SQL kadar güçlü bir yöntemle sorgulamamızı ve performans açısından otomatik ön bellekleme yapılmasını sağlar. Ayrıca veritabanı şemasında yapılan bir değişiklikte (veri erişim katmanındaki sınıflar doğrudan veritabanına bağlı olmadığı için) veri erişim kodlarını gözden geçirmek yerine daha önce oluşturulmuş olan xml tabanlı nesne-tablo eşleştirme dosyasının düzenlenmesi yeterli olacaktır.
O/R Mapping yönteminde kullanılmak üzere birçok araç geliştirilmiştir bunların en popüleri ilk olarak Java platformu için çıkarılmış ama daha sonra .NET sürümü de geliştirilmiş olan açık kaynak NHibernate ürünüdür (www.hibernate.org). Bunun dışında başta LLBLGen ürünü olmak üzere .NET platformunda kullanılacak birçok O/R Mapping aracı bulunmaktadır. Günümüzde birçok yazılım evi, uygulamalara ait ORM kodu üreten framework’ler geliştirmiştir. Bu araçlar kullanılarak sorgulama cümleleri elle yazılmak yerine otomatik olarak üretilir ve veri erişim katmanı kısa sürede oluşturulmuş olur. Dolayısıyla yazılım mühendisinin veri erişim ve sorgulama için ayıracağı kodlama zamanını iş katmanındaki algoritmaya ayırması, o alana odaklanması, veri erişim katmanını düşünmemesi sağlanmış olur.

Bir diğer konu da ugulamalar içerisinde veritabanı işlemleriyle ilgili kodların çalıştırılma yönteminin ne olacağıdır. Bu yöntemin ne olacağı yazılım uzmanları arasında birçok tartışma konusu olmuştur. .NET Framework’ün ilk sürümlerinde iş katmanında dinamik SQL yerine SQL yordamlarının (stored procedure) kullanılması tavsiye edilmiştir. Bu yöntemin daha fazla güvenlik ve hız kazandırdığı dile getirildi. Ancak günümüzde bu yöntemin güvenli olduğu kabul edilse de performans ve kullanım konusunda fikir birliği sağlanamamıştır. Stored procedure yerine dinamik SQL kullanılmasını tavsiye edenlerin dayanağı; stored procedure’lerin versiyonlama, taşınma ve kurulumun kolay olmaması ve büyük ölçekli kurumsal uygulamalarda iş kurallarının genişlemesiyle birlikte yönetimi ve bakımı zorlaşacak çok sayıda procedure yazmak zorunda kalınmasıdır. Aslında asıl sorun iş katmanı ve veri katmanı sınırlarının iç içe geçmesi ve ilk paragraflarda bahsettiğimiz gibi uygulama geliştiricinin veri katmanında çok zaman harcamasıdır. Veritabanının doğası gereği görevi veri arama, tarama olduğu için kod güvenliği, matematiksel işlemler, koşula dayalı işlemler gibi ek faaliyetlerle uğraşmaması gerekir. Bununla birlikte farklı türden veritabanı üzerinde çalışma ihtimali olan paket haline getirilecek bir ürün için iş kurallarını stored procedure üzerinde oluşturmak uyarlama sürecini zorlaştıracak, zaman kaybına neden olacaktır. Stored procedure’lere alternatif olarak dinamik SQL yapısının kullanılması da uygulamayı, veritabanı şemasına bağımlı hale getirecektir. Bu yüzden O/R Mapping yöntemini kullanarak iş katmanını SQL kodlarından temizleyip bu katmanın sadece iş mantığı algoritmasını içermesini ve uygulama geliştiricinin de sadece o katmana odaklanmasını, T-SQL ile boğuşmak yerine sadece OOP destekli dil ile işlemlerini yürütmesi sağlanmalıdır. ORM yöntemini tercih ettiğimizde aşağıdaki gibi bir T-SQL cümlesi veya stored procedure yerine

UPDATE Musteri SET AdSoyad='Murat Şensoy'
WHERE MusteriId = 10

aşağıdaki gibi bir kod yazmış olacağız.

Musteri.AdSoyad = "Murat Şensoy"
oRm.Save(Musteri)

Görüldüğü gibi CRUD (create, read, update, delete) işlemlerini OOP kurallarına göre yazmış oluyoruz. Böylece iş katmanını kodlayan yazılımcının yöntem alışkanlığı bozulmamış olmaktadır.
O/R Mapping modelinin geliştirme sürecinde kolaylık sağlamasına karşılık çalışma zamanında klasik yöntemle kıyaslandığında performans konusunda yeterince iyi olduğunu söyleyemeyiz. Bunun nedenlerini şu şekilde sıralayabiliriz:

  • ORM, uygulama mimarisine veri erişim isminde yeni bir katman ekler.
  • Veri katmanı, veritabanına doğrudan erişemez.
  • SQL dilinin kompleks sorgu oluşturma ve çözmedeki gücünden yararlanılmaz.
  • ORM, uygulamanın veritabanı bağımsız olmasını sağladığı için o anda kullanılan VTYS’nin yeteneklerinden yararlanılamaz.

Sonuç olarak O/R Mapping yönteminin zorunlu bir yöntem olmadığını ancak kompleks iş katmanına sahip büyük ölçekli kurumsal uygulamalarda veri erişim katmanını daha az kodla ve kısa sürede üretmeye yardımcı olduğu ve sonuçta yazılım mühendisinin üzerindeki yükü hafiflettiği için tercih nedeni olabileceğini söyleyebiliriz. Bu yöntemi kullanıp kullanmamak birazcık ta “uygulama içerisinde klasik veri sorgulama ifadelerini (select, insert, update, delete) SQL ile manual mi oluşturacağız yoksa bunlar otomatik mi oluşturulmalı?” sorusuna vereceğimiz yanıta bağlıdır.
Tanımını, avantaj ve dejavantajını verdiğimiz ORM yönteminin .NET cephesindeki durumunu inceleyelim.
ADO.NET Entity Framework
Microsoft, ADO.NET 2.0 ile birlikte sunduğu ObjectSpaces (OS.Net) ürünüyle O/R Mapping çözümüne ilk adımını atmış oldu. ADO.NET 3.5 ile birlikte ObjectSpaces ürününü yeniden düzenleyerek ADO.NET Entity Framework isimli eklentiyi geliştirerek O/R Mapping alanındaki adımlarını daha da belirginleştirdi.
Entity Framework eklentisi, sadece bir O/R mapping aracı veya bir code generator olmanın ötesinde bunları da içinde barındıran ve uygulama içerisindeki varlıkları ve ilişkilerini sorgulamamızı sağlayan servisler bütünüdür. Entity Framework’ün servisleri aşağıdaki şekilde gösterilmiştir.

ADO.NET Entity Framework’ün bir parçası olarak Framework ortamında ER modelinin oluşturulması için Varlık Veri Modeli (Entity Data Model-EDM) isimli konsept sunulmaktadır. EDM’yi veritabanı şemasını kavramsal ve mantıksal boyutta gösteren ve ilgili ORM haritasını oluşturan bir araç olarak değerlendirebiliriz. EDM, varlıklarla ilgili şemayı XML belgelerinde (CSDL, SSDL, MSL) saklar. Bu üç dosya, Entity Framework’ün üç temel boyutu olan kavramsal (conceptual), mantıksal (logical) ve haritalama (mapping) modelleriyle ilgili bilgileri içerir.
CSDL (Conceptual Schema Definition Language): Varlıkların ve onlara ait ilişkilerin tanımlandığı dosya olup uygulamanın çekirdek veri modelini (core data model) teşkil eder. Uygulama katmanında varlıklar (nesneler), CSDL şeması referans alınarak oluşturulur. Bu şema, kavramsal şema formatına sahiptir.
SSDL (Store Schema Definition Language): Veri kaynağı olarak kullanılacak veritabanına ait üstveri (metadata) bilgisini içerir. Mantıksal model için oluşturulan bu dosya, varlıklarla veri kaynağı arasındaki iletişimi kurar.
MSL (Mapping Specification Language): CSDL dosyasındaki varlıkları SSDL dosyasında belirtilmiş tablolarla eşleştirir.

Entity Client, SQLClient, OracleClient gibi ADO.NET’in bir yönetilebilir veri sağlayıcısı (managed provider) olup EDM tarafından tanımlanmış olan veriye erişmeyi sağlar. Diğer sağlayıcılar gibi bunun da EntityCommand, EntityConnection ve EntityTransaction bileşenleri bulunur.
Object Services bileşeni, veri nesneleri üzerinde CRUD (Create, Read, Update, Delete) işlemleri için gerekli sorguları oluşturur. Bu sorgulama servisi, “Entity SQL” ve “LINQ to Entities” türü sorgulama destekler. Entity SQL (eSQL) ismindeki sorgulama dili, T-SQL’ dilinden türemiş olup EDM modelindeki varlıkları ve aralarındaki ilişkileri sorgulamak için kullanılır. LINQ to Entities bileşeni de daha sonra yazılarda anlatacağımız LINQ teknolojisinin varlıkları sorgulamak için sunduğu bir sağlayıcıdır.

Yeni Nesil Veri Programlama Modeli (ADO.NET 3.5)” hakkında 0 yorum

  1. Coşkun

    Ahmet bey Ankara da kitabınızın 2. cildini bulamıyorum eğer ücretini göndersem bana gönderme şansınız olurmu. Şuan ihtiyacım var ve başka kitap almak istemiyorum. Yardımcı olursanız sevinirim.

    Cevapla
  2. Ahmet Kaymaz Yazar

    Coşkun Bey,sizin kadar ben de C#’ın 2. cildini ve ASP.NET serisinin çıkmasını dört gözle bekliyorum :) . Editörün, Türkçe uzmanının, yayın danışmanının çalışmaları sıkı geçtiği için malesef gecikmeler yaşanabiliyor. Bu cuma son gözden geçirme işlemi olacak. Önünümüzdeki hafta baskıya verilecek. “İleri Düzey Programlama” olarak çıkacak olan 2.cildin özellikle ADO.NET ve LINQ konularında önemli bir katma değer sağlayacağını düşünüyorum. Bu yüzden eğer vaktiniz varsa ayın 15’ine kadar beklemenizi tavsiye ederim.Bu arada eğer hazır olsaydı ücrete gerek kalmadan size hediye olarak gönderirdim. İlginiz ve sabrınız için teşekkür ederim,

    Cevapla
  3. Coşkun

    Ahmet bey çok teşekkürler. Bekliyorum. Çalışmlarınızın devamını dilerim. Saygılar

    Cevapla
  4. ahmet

    sefer alganın bloğunda microsoftun linq desteğini artık vermeyeceği ve gelişimini durduğu yazıyo. Bunları göze alarak linq kullanmayı hala tavsiye ediyormusunuz.

    Cevapla
  5. Ahmet Kaymaz Yazar

    Ahmet Bey,Microsoft’un LINQ’yu desteklemeyeceğini belirten resmi yazıyla hiç karşılaşmadım. Sadece “LINQ to SQL” ilgili kuşkular mevcut. Yani MS, LINQ’yu değil “LINQ to SQL” aracını değiştirmek istediğini hatta son açıklamalarda yine de devam edeceğini ifade etmiştir. “LINQ to SQL” LINQ yaklaşımının veritabanı tarafıyla ilgilidir. Fakat şu anda sadece SQL Server için geçerli olması bir eksiklik olduğu için MS, bu ürünü Entity Framework adı altında daha güçlü kılmayı hedeflemektir. Meseleyi “LINQ to SQL” yerine ORM olarak görmek gerekir. Microsoft’un ORM konusunda sağlam olarak attığı bu adımdan vazgeçeceğini sanmıyorum. Sadece bu ürün NHibernate gibi biraz güçlenmeye ve VTYS’den bağımsız hale getirilmeye ihtiyaç duymaktadır. Yine de şu an için birşey söylemenin erken olacağını, gelişmeleri takip etmenin daha doğru olacağını düşünüyorum. Aşağıdaki linkte bu konu detaylı tartışılmıştır. Bu makalede MS’un ORM tarafını C# ekibinden alıp ADO.NET ekibine teslim ettiği de yazılmaktadır ki bu doğru bir adım olacaktır. http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspxSonuç olarak “LINQ to SQL” kullanılmasa da Entity, Object, DataSet, Collection, XML gibi yapılar için LINQ kullanımına devam etmeliyiz.

    Cevapla
  6. Birol Erol

    Merhaba Ahmet Hocam.
    Şimdi entity fram. ile bir Linq to entities ve birde Entities SQL var bunlarında aralarında ki farklar entity sql de objectquery ile bildiğimiz sql cümlelerini yazıyoruz. Hangisi kullanılmadı linq miyoksa ESQL mi?
    Ve birde EntityCommand ile bildiğimiz SQLCommand entity olarak kullanmamızı sağlamış. Açıkçası biraz kafam karıştı desem yalan olmaz hocam.

    Cevapla
  7. Ahmet Kaymaz Yazar

    ADO.NET Entity Framework, Microsoft’un ORM(Object Relational Mapping) yöntemi üzerine kurulu yeni nesil veri erişim platformudur. Fiziksel veritabanı şemasına karşılık mantıksal bir şema oluşturup sözkonusu veritabanı nesnelerinin nesne tabanlı programlama yaklaşımıyla sorgulanmasını sağlar. Sorgulama işlemi LINQ To Sql veya Entity SQL aracılığıyla gerçekleştirilir. Entity SQL ismindeki sorgulama dil yapısının asıl amacı EDM(Entity Data Model) üzerindeki varlıkları sorgulamaktır. Entity SQL ile ilgili aşaığıdaki linkler faydalı olabilir.http://msdn.microsoft.com/en-us/library/bb387145.aspxhttp://blogs.msdn.com/zlatkom/archive/2007/07/10/entity-sql.aspx
    ESQL ve LINQ to Entities arasındaki bazı farklar için aşağıdaki linki inceleyebilirsiniz.http://blogs.msdn.com/diego/archive/2007/12/20/some-differences-between-esql-and-linq-to-entities-capabilities.aspx

    Cevapla
  8. Berat USLU

    Yine harika bir yazı. hocam çalışmalarınızın ve kitaplarınızın devamını bekliyoruz.

    Cevapla
  9. ramazan celikkaya

    hocam yazınız gerçekten çok yararlı olmuş ozellikle ado.net entity framework konusunda açıklayıcı bir yazı arıyordum , yazınızı okudum istifade edilecek tarzda. tskler.

    Cevapla

Coşkun için bir cevap yazın Cevabı iptal et

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir