ADO nedir?
Neden ADO ?
“ADO” basit ve zengin bir fikir olarak ortaya atılmıştır. Bunu şu şekilde
açıklayabiliriz: “Veriye erişebilmek için sadece bir yolunuz vardır” . Bu teknoloji yeni bir
teknoloji değildir, uzun zamandır kullanılmakta olan ve gelecekte de kullanılacak olan bir
teknolojidir. Ama gelecekte bir çok yeni teknolojinin (DAO ve ODBC gibi) geliştirilmekte
olan bir çok uygulama için biçilmiş kaftan olacağı da bir gerçektir.
Daha önceleri veritabanı programcılığı ile uğraşanlar ODBC ve RDO’yu yakından
tanımaktadırlar. Open Database Connectivity (ODBC) bir Aplication Programing Interface
(API) olup “Access” ve “SQL Server” gibi veri kaynaklarına erişebilmektedir. Bir API
olmasından dolayı birçok uygulama geliştirici ODBC’yi (özellikler Visual Basic alanında)
komplike bulmaktadır. Remote Data Object (RDO) ise ODBC’nin en üst katmanında yer
alan bir ActiveX’dir. ODBC ile tamamen tümleşik çalışmaktadır fakat çok daha kolay
kullanışlıdır. Genel anlamda OLE DB ile ODBC’yi ve ADO ile RDO’yu eşleştirebiliriz.
OLE DB ve ADO Yapıları
Şimdiye kadar OLE DB ve ADO ile ilgili yüzeysel bilgi verdik fakat birbirleri ile olan
ilişkilerini ancak bir diyagram üzerinde anlayabiliriz. Bu diyagramda uygulamalar ile veri
kaynakları arasında nasıl bir ilişki olabileceği hakkında bilgi verilmiştir.
Diyagramdan da görüleceği gibi en üst seviyede uygulamalarımız yer almaktadır (bir
web veya normal bir uygulama olması hiç fark etmez). Bu katmanın hemen altında ADO
ve/veya OLE DB veri kaynağından alınan verileri uygulamaya iletmek için yer alırlar.
Fakat OLEDB tüm programlama dilleri ile beraber çalışabilecek şekilde değildir bundan
dolayı ADO, OLEDB üzerinde bir geçiş katmanı görevi yapmaktadır. ADO OLEDB ile
OLEDB’nin desteklemediği diller arasında bir arabirim görevi yapmaktadır. ADO OLEDB ye
göre çok daha kolay bir programlama arabirimine sahiptir bu sebepten dolayı direkt OLE
DB erişimi (kullanımı) olabilen programlama dilleri (C++ ve Java gibi) veri kaynağına
erişimlerini daha kolay hale getirebilmek için ADO kullanabilmektedirler.
Diyagramda sadece Microsoft programlama dilleri gösterilmiştir fakat ADO’nun bir
COM bileşeni (component) olduğu düşünülürse ADO diğer COM destekli programlama
dillerinde de (Delphi veya Active Scripting Interface destekleyen Script dilleri)
kullanılabilmektedir. Şüphesiz ki VBScript ve Jscript içeren ASP sayfalarımızda da ADO
bileşenini kullanabiliriz.
Data erişimi için OLEDB ve ADO kullanılabileceğini öğrendik. Peki ya neden? Eski
metodları neden kullanmıyoruz? Bunun iki büyük sebebi var.
Birinci sebep OLEDB ve ADO’nun bir “Veri Kaynağına” erişmek için tasarlanmış
olmasıdır. Dikkatinizi çekerim “Veri Tabanı” demedim “Veri Kaynağı” dedim. Veri tabanları
en çok kullanılan veri kaynağı da olsa birçok uygulama (mesajlaşma sistemleri,
Microsoft Exchange Server, Dizin Hizmetleri ve tabi ki Web Sunucuları) veritabanı dışında
bir yapı kullanmaktadırlar.
İkinci sebep ise İnternet uygulamalarının hızla yaygınlaşmasıdır. Eski data erişim
metodları webden data erişimi için geliştirilmemiştir.
Destekleyiciler ve Sürücüleri
Unutulmaması gereken bir nokta da ODBC için OLEDB destekçilerinin olduğudur. Bu
OLEDB’nin ODBC data kaynaklarına erişmesinde bir aracıdır. ODBC için geliştirilen
sürücüler (Destekleyiciler tarafından) mevcuttur bu sürücüler sayesinde ODBC esnek bir
yapıya sahip olur. Diyagram 4 ADO bağlantı yapısındada görüldüğü gibi veri erişiminde de
çeşitli katmanlar vardır.destekleyiciler ODBC katmanında yer alırken sürücüler ise ODBC
katmanında yer almaktadır. Eğer bir ODBC data kaynağı kullanmak istersek ODBC için bir
OLEDB destekleyicisi kullanmamız gerekir. şayet ODBC data kaynağı kullanmak istemezseniz
o zaman bir OLEDB destekçisi kullanmanız gerekir.
ADO 2.5 Obje Modeli
ADO 2.5 obje yapısı bir önceki versiyonuna göre çok daha basit bir yapıdadır. Bir
önceki versiyonuna ek olarak iki yeni obje eklenmiştir. Diyagram 5 : ADO Obje Yapısı. da
bu yapıya ait diyagram verilmiştir.
Eğer daha önceden ADO kullanmış iseniz(eski versiyonları) Stream ve Recordobjelerinin yeni
eklendiğini fark edebilirsiniz.
Connection Objesi
“Connection” objesi data kaynağına bağlanmak için kullanılmaktadır. Bu obje
saye EDB destekçisinin kullanmak istediğimizi belirtebiliriz. Connection
objesi data kaynağına bağlanmak için tek yol değildir. Command, Recordset ve Record
objelerin objesini daha çok bağlantıya ait özellikleri belirtmek için kullanırız. Eğer destekleyici
üzerinden bir dizi komut çalıştırmak isterseniz Connection objesini kullanmanızı öneririz.
Command Objesi
Command objesi data kaynağı üzerinden komutlar çalıştırmak için tasarlanmıştır.
Fakat bir dakika “Connection objesi de bunu yapabilir diyenlerinizi duyuyorum. Evet ama bir
farkla Connection objesinden çalıştırılacak bir komut araka alanda yine command objesini
çalıştırır. Bir komut çalıştırdığımız zaman geriye bir dizi kayıt alırız. Command objesi geriye
kayıt döndürmeyen komutların kullanımı içinde uygundur.(yeni kayıt eklemek veya kayıt
güncellemek için kullanılan SQL sorguları buna örnektir.
Recordset Objesi
Recordset objesi ADO içerisinde en çok kullanılan objedir. Bu obje data kaynağından
aldığı veriyi bir dizi şeklinde bize sunar. Bu obje sayesinde ADO bize veriler üzerinde
değişiklik yapmamıza, kayıtları taşımamıza ve kayıtları filtrelememize izin verir.
Recordset objesi “Fields” koleksiyonunu içerir. Bu koleksiyon sayesinde veri kaynağındaki
tüm alanlara (kolonlara) erişebiliriz.
Record Objesi
ADO’nun daha önceki versiyonlarında veriyi işlemek ve kayıt setleri oluşturmak
şimdiki gibi kolaydı, ama sadece veri tabanlarında yani belirli bir kolon yapısına ve data
yapısına sahip olanlar için. Bunlar dışında kalan dosya ve posta sistemlerinin veri
kaynakla rı için kullanılamıyordu. Bu tip veriler için 2.5 versiyonunda “Record” objesi
geliştirildi.
Bu tip yarı biçimlenmiş veri kaynakları bir ağaç yapısı şeklinde olurlar,yani ana
düğümler ve alt düğümler içerirler. Resim 8 IIS Ağaç yapısı .de görülen bir web
sunucusunun yapısıdır. Görüleceği üzere “test” ana düğümü altında “database
ve images” gibi alt düğümler mevcuttur.
Bu düğüm noktaları da kendi içerisinde bir çok dosya barındırır. Bir asp dosyası, bir
metin dosyası ve bir Word dosyası bunları kafanızda bu ağaç yapısında olduğu gibi hayal
edebilirsiniz. Dosya adının yanı sıra tür, son erişim tarihi ve boyut gibi bilgileri de bu
yapıya ekleyebiliriz. Peki ya erişimler yani kullanıcıların nerelere erişeceklerini ve nelere
erişemeyecekleri.
Tüm bu yapının kompleks haline Record objesi adı verilir
Stream Objesi
Stream objesi Record objesinde açılan düğümleri okumak için kullanılır (web sunucu
veya bir elektronik posta ya erişim yapamaz ama içeriğini okuyabilir). Bundan dolayıdır ki
Record ve Recordset objeleri ile bütünleşik çalışır.
Stream objesinin bir diğer önemli kullanım alanı da XML dosyalarına erişimdir (XML
verisi yukarıda anlatılan yarı-yapılandırılmış data yapısındadır).
Stream objesi binary verileri işlemek içinde kullanılabilir. Buna örnek olarak resim
işleme veya büyük boyutlu metin veri tabanları gösterilebilir.
Parametreler Koleksiyonu
Parametre koleksiyonu sadece Command objesi ile birlikte kullanılır. Ve komutların
parametrelerini belirlemeye yarar. En çok kullanım alanı SQL Server’da bulunan “Stored
Procedure” dır. Bu özellik sayesinde SQL Server’da önceden ayarlanmış olan SQL
komutları işletilmiş olur. Bu çok kullanışlı bir özelliktir ve zamandan kazandırır.
Bir diğer özelliği ise komut çalıştırılmasından sonra geriye dönen değer eğer tek bir
veriden oluşuyorsa yani bir set şeklinde değilse o zaman parametre özelliği olarak geri
döndürülür.
Anasayfa 