Veri Erişim Arayüzleri

OLE-DB popüler olsa da, OLE-DB için bazı eksiklikler vardı. İlk olarak, OLE-DB, başvuruları veya işaretçileri çok iyi desteklemeyen belirli programlama dillerinde çok az veya hiç desteği vardır. Ayrıca, OLE-DB katmanlı yapısı ODBC gibi küçük bir API katmanı üzerinde potansiyel olarak performans etkileri olabilir. Bu eksiklikler ek veri erişim arabirimlerinin oluşturulmasına yol açtı.

DAO

OLE-DB oluşturulduktan sonra çok uzun sürmedi, Microsoft, bireylerin yerel makinelerinde bir veritabanını hızlı bir şekilde kurmalarına ve yönetmelerine izin veren yeni bir uygulama (Microsoft Access) yaratıyordu. Microsoft Access’in bekleyen sürümü aynı zamanda yeni bir veritabanı yönetim motoru (JET) de çıkarıldığı anlamına geliyordu. Hem Microsoft Access hem de diğer veritabanlarını sorgulamayı desteklemek için Veri Erişim Nesneleri (DAO) oluşturuldu. DAO doğrudan Microsoft Access veritabanlarına bağlanmak için JET altyapısı kullanır. Diğer veritabanı altyapısı istekleri bunun yerine ODBC üzerinden yönlendirilir.

Access veritabanlarını düzenli olarak sorguluyorsanız DAO harikaydı. Diğer veri kaynakları için DAO, ODBC bağlantısını kullanarak direkt olarak JET Engine üzerinden yönlendirme ek yükü ekledi. Bu yük, geliştiricilerin ODBC’yı doğrudan kullanmalarına veya Microsoft Access olmayan veritabanlarını sorguluyorlarsa alternatif aramasına neden oldu.

RDO

Uzak Veri Nesneleri (RDO) DAO üzerinde tüm istekleri doğrudan ODBC üzerinden yönlendirecek şekilde geliştirmeye çalıştı. İstek Microsoft Access’i hedef almışsa ODBC, ODBC aracılığıyla isteği yönlendirecektir. ODBC, diğer veritabanları için yerel olarak istekleri çevirebilir.

RDO modeli, DAO için paradigmayı tersine çevirdi, ancak şimdi Microsoft Access’i hedefleyen uygulamalar için gereksiz yük getirdi. Geliştiriciler artık uzlaşmanın olmadığı bir çözüm arıyorlardı.

ADO

ActiveX Data Objects (ADO), gerçek bir basit tüketici ve sağlayıcı modeli uygulayarak paradigmayı düzleştirdi. Bu modelde, uygulama ADO kütüphanelerini kullanan bir tüketici olarak hareket etti. Sağlayıcı tarafı için ADO, geliştiricilerin ve şirketlerin herhangi bir veritabanı için optimize edilmiş sağlayıcılar uygulayabilecekleri bir ‘eklenti’ modeli uyguladı. Örneğin, SQL veritabanlarını sorgulamak için bir SQL sağlayıcısı kullanabilirsiniz. Sağlayıcılar ayrıca Oracle gibi veritabanları ve Active Directory ve Access gibi uygulamalar için de varlıklardı.

ActiveX Data Objects (ADO)

ActiveX Data Objects (ADO), geliştiricilerin çok çeşitli veritabanlarıyla etkileşimde bulunmalarına olanak tanıyan bir tüketici arabirimidir. ADO, bir tüketici ve sağlayıcı modelini uygulayarak bu başarıyı gerçekleştirir. Bu modelde, arabirim tüketici uygulamalarında doğrudan bir veri kaynağından veri sorgulamak ve işlemek için kullanılır. Ayrı ayrı sağlayıcılar, veritabanı yazarları veya belirli herhangi bir veri kaynağıyla etkileşim kurmak için platforma özgü mantığı uygulayan diğer geliştiriciler tarafından oluşturulur.

Bir ADO Örneği olarak, üretimde bir Oracle veritabanına basit SQL sözdizimi sorguları yapan bir uygulama olabilir. Lisans kısıtlamaları nedeniyle, kendi geliştiricileriniz yerel makinelerinde SQL Server Express LocalDB’yi kullanabilir. ADO bu varsayımsal senaryoyu birkaç şekilde desteklemektedir.

İlk olarak, uygulama kodunuz genelleştirilmiş ADO arabirimini kullanır. Bu örnekte, mantığını ADO’yu kullanarak uygulayabilir ve platforma özgü herhangi bir kodu hariç tutabilirsiniz.
Geliştirmede, uygulamanız ADO için SQL Server sağlayıcısını kullanabilecektir. Bu sağlayıcı, SQL Server’a özgü mantığı uygular.
Üretimde, uygulamanız alternatif olarak ADO için Oracle sağlayıcısını kullanacaktır. Bu sağlayıcı, Oracle’a özgü mantığı uygular.