Command (Komut) Nesnesi
Command nesnesi, veri kaynaklarına karşı icra edilecek komutları temsil eden ADO.NET
nesnesidir. ADO'daki Command nesnesi ile benzer özelliklere sahiptir.
Command nesnesi de bir Provider nesnesidir ve temsil ettiği komutları icra
ettirebilmesi için kurulmuş (açık) bir bağlantıya ( Connection nesnesine) ihtiyacı
vardır. Bu nedenledir ki açık bir bağlantıyı, Command nesnesi ile ilişkilendirmeden,
onu bir komut icra ettirmek için kullanamayız.
Command nesnesi bize neler sağlar?
* Direk SQL sorguları yürütebiliriz. (SELECT, INSERT, UPDATE, DELETE ve diğer
DDL komutları CREATE, ALTER, ..)
* Depolanmış prosedür (Stored Procedure) işletimi yaptırabiliriz.
* Depolanmış prosedürler için çeşitli değer aktarım tiplerinde (INPUT, OUTPUT, RETURN
VALUE) parametreler bildirebiliriz.
* Yürüttüğümüz sorgu (veya stored procedure) sonucu dönen kayıtlara bir DataReader
nesnesiyle ulaşabiliriz.
* Direk bir tablo adını yazarak tüm kayıtlarını döndürebiliriz.
* Tek bir satır veya tek bir skaler değer döndüren sorgular için iyilenmiş
işletim metodlarını kullanabiliriz.
* Command nesnemizi, bir Transaction nesnesi ile ilişkilendirip ADO.NET seviyesinde
Transaction imkânını kullanabiliriz.
Açıktır ki, Command nesnesi ADO.NET'in hayati bileşenlerinden birisi. Connection
nesnesi sadece, uygulamamamızın veritabanı ile olan canlı ilişkisini temsil ederken,
Command nesnesi bu ilişki üzerinden yürüyen her türlü alış/verişi temsil
ediyor.
Her seferinde tekrarlamak sıkıcı ama, bunun gerekli olduğu da bir gerçek. System.Data.SqlClient
sağlayıcısı ile SqlCommand ve SqlDataReader nesnelerini, System.Data.OleDb sağlayıcısı
ile OleDbCommand ve OleDbDataReader nesnelerini kullanmamız gerekiyor. MS SQL Server
7 (ve üst sürüm) veritabanları için SqlClient sağlayıcısını tercih ediyoruz.
OLE DB desteği olan veri kaynaklarına da OleDb sağlayıcısıyla bağlanmaya
devam ediyoruz. ( Bu iki sağlayıcının isimlerini açık yazmak yerine, Framework sınıf
kütüphanesinde temsil edildikleri aduzayı (namespace) tanımlarını yazmayı yeğledim.
Bilginize. )
NOT
Bu yazıyı okumadan önce, .NET'te Veri Erişimi
: ADO.NET ve Connection (Bağlantı)
Nesnesi başlıklı makaleleri okumanızı salık veriyorum.
Bir Command Nesnesi Oluşturmak
Bir Command nesnesini, parametresiz sınıf yapılandırıcısı (constructor) ile
oluşturmak mümkündür. ( Örneklerimizi tekrardan kaçınmak için sadece SqlClient için
vereceğiz. OleDb için de aynı örnekleri, nesne adlarında ve dahil edilen aduzayında
ufak değişiklikler yaparak kendiniz yazabilirsiniz. )
|
// nesne referansımızın bildirimi SqlCommand cmdTest; // ve referansımıza yeni bir SqlCommand nesnesinin oluşturulması ve bağlanması |
Örnek kodda, bir SqlCommand nesnesi oluşturduk, yalnız bu nesneyi bir SqlConnection
nesnesi ile ilişkilendirmedik. Şimdi connNorthwind adında bir SqlConnection nesnemiz
olduğunu varsayalım. Bunu cmdTest nesnemiz ile ilişkilendirelim:
|
cmdTest.Connection = connNorthwind; |
Yürüteceğimiz komutu da CommandText özelliğine atayarak bildiriyoruz.
|
cmdTest.CommandText = "SELECT * FROM Employees"; |
Ancak tüm bu yaptığımız işlemleri, tek satırda da yapabilirdik. Çünkü SqlCommand
sınıfı, parametreli yapılandırıcılar da sunuyor. İşte tek satır:
|
SqlCommand cmdTest = new SqlCommand( "SELECT * FROM Employees", connNorthwind ); // Nesneyi, CommandText ve Connection özelliklerini, // yapılandırıcıda belirleyerek oluşturduk. |
Aslında Command nesnesini oluşturmanın daha pratik bir yolu var. Yukarıda hep SqlCommand
yapılandırıcı metodunu kullandık. Şimdi yapılandırıcı kullanmadan, Connection
nesnesinin CreateCommand() metodu ile Command nesnesi oluşturmayı göreceğiz. Bu
metod, bir SqlCommand nesnesi döndürüyor:
|
SqlCommand cmdTest = connNorthwind.CreateCommand(); |
Peki yukarıdaki yöntemle bir SqlCommand nesnesi oluşturduğumuzda farklı olan bir
şey olur mu? Evet. Oluşan SqlCommand nesnesi otomatikmen bağlantınız ile ilişkilendirilmiş
olacaktır. Yani bu örnek için konuşursak, cmdTest nesnesinin Connection özelliği,
connNorthwind bağlantı nesnesine otomatikmen bağlanmıştır.
.NET Framework sınıf kütüphanesindeki çoğu nesnede olduğu gibi Command nesnelerinin
de (SqlCommand, OleDbCommand) bir çok şekilde oluşturulabildiğini gördük. Bunların
tek tek makalelerde anlatılması zordur. Bu tip alternatif yöntemler için başvuracağınız
yegane kaynak .NET Framework SDK Dokümantasyonu olmalıdır. Bu dokümantasyonda,
bir sınıfın "Overload" edilmiş tüm yapılandırıcılarını ayrı ayrı görmeniz ve bilgilenmeniz
mümkündür.
CommandText ve CommandType Özellikleri
Command nesnesinin veri kaynağında icra edilmek üzere göndereceği emir cümlesini,
bir string ifade olarak CommandText özelliğine atıyoruz. (Veya az önce belirttiğimiz
gibi parametreli yapılandırıcıda iken bildiriyoruz.)
| cmdTest.CommandText = "SELECT * FROM Employees"; |
Ancak bu emir ifadesinin nasıl yorumlanacağı da önemlidir. Bir komut üç tipten birinde
yorumlanabilir: 1 - SQL ifadesi olarak, 2 - Depolanmış prosedür çağrısı olarak, 3
- Direk tablo adı olarak. Bunlar arasında ilk belirttiğimiz SQL ifadesi
(Text), komutun öntanımlı tipidir. Komut tipini değiştirmek için Command nesnesinin
CommandType özelliğini kullanıyoruz. Bu özellik, System.Data.CommandType sıralaması
(enumeration) tipinde bir değer alıyor.
|
// Dahil etmeniz gereken aduzayları: System.Data ve System.Data.SqlClient
cmdTest.CommandText = "SELECT * FROM Employees"; /* |
Yukarıda verdiğimiz komutlar, parametre istemeyen komutlardı. Ama çoğunlukla yürüteceğimiz
sorgu veya prosedür için parametre kullanma ihtiyacı doğacaktır. Örneğin bir tablodan
belirli bir kritere uyan kayıtların seçilmesi durumunda komutla beraber parametre
aktarımı gerekecektir. Bunun en kestirme yolu, komut metnini parametrelerle beraber
yazmaktır elbette:
|
string ulke = "Germany"; // Bu değerin kullanıcıdan alındığını varsayalım string strSQL = "SELECT * FROM Customers WHERE Country='" + ulke + "'"; cmdTest.CommandText = strSQL; |
Bu komut güzelce çalışacaktır. Ancak burda durum çok basittir. Çoğunlukla daha karmaşık
sorgularla karşılaşacağız. Parametre listesinin uzadığı komutlarda, bu tip bir "concatenate"
işlemi gerçekten çok zor ve zahmetli olacaktır. Depolanmış prosedürlerde ise durum
daha ciddidir. Çünkü depolanmış prosedürler, farklı parametre tiplerini desteklemektedirler.
Ve parametreler için veri tipleri belirlenmektedir (sayısal, ondalıklı, para, karakter,
..). İşte parametreler ile ilgili tüm bu ayrıntılı bilgiyi ifade edebileceğimiz
bir yapıya ihtiyaç vardır: Parameter nesnesi. Parameter nesnesi, bağımsız bir parametreyi
temsil eder. Öte yandan Command nesnesinin Parameters adında bir kolleksiyon özelliği
vardır. Ve tahmin ettiğiniz gibi, bu kolleksiyona komut metni ile ilişkilendirilmiş
parametrelerin eklenmesi gerekiyor.
Parametreler ile ilgili bahsi, sadece bu konuya tahsis edilmiş farklı bir yazıda
tekrar açmak üzere burada kapatıyoruz.
Komutu İcra Ettirmek
Bir Command nesnesine yaptıracağımız nihai iş, temsil ettiği komutu icra ettirmektir.
Yalnız komutu icra ettirme noktasına gelmek için Command nesnesinin buna hazır olduğundan
emin olmalıyız. Açalım. Command nesnesi bir Connection nesnesiyle ilişkilendirilmiş
olmalıdır. Bu yetmez; Connection nesnesinin temsil ettiği bağlantı açık olmalıdır.
Command nesnesinin CommandText özelliğine icra edilecek komut belirtilmelidir ve
gerekiyorse CommandType özelliği ayarlanmalıdır.
Eğer yukarıdaki hazırlık aşamaları tamamlanmışsa, Command nesnesinin ifade ettiği
komutu kolaylıkla icra ettirebiliriz (execute). Ancak ADO.NET, ADO'dan
farklı olarak, sorgudan dönecek sonuç için özelleşmiş (ihtisaslaşmış) 4 ayrı Execute
metodu sunmaktadır:
ExecuteReader() : Bu metod kayıt döndürecek komutlar için özelleşmiştir. İşletimi
sonucu kayıt setini ifade eden bir SqlDataReader nesnesi oluşturur. SqlDataReader
nesnesi kapanana kadar, bağlantı üzerinde komut yürütülemez.
ExecuteNonQuery() : Veri seti döndürmeyen komutlar için özelleşmiştir. Dönüş değeri,
sorgunun işletiminden etkilenen kayıtların (records affected) sayısıdır.
ExecuteScalar() : Sorgu sonucu tek bir değer dönecekse bu metodu kullanmamız daha
uygundur. Örneğin bir kümeleme (aggregation) sorgusunda.
ExecuteXMLReader() : Sorgu sonucu bir XMLReader nesnesi oluşturur.
Bundan sonraki DataReader konulu yazımızda, ExecuteReader() metodu üzerinde ayrıntılı
olarak konuşacağız. Şimdilik basit bir örnekleme yapalım:
| SqlCommandDeneme.cs | |
|
using System; using System.Data; using System.Data.SqlClient; namespace Makaleler // bağlantı ve komut nesnelerimizi oluşturalım // bağlantı cümlesi verip, Northwind ile aktif bir bağlantı kuralım // komutu, canlı bağlantımız ile ilişkilendirelim // bir stored procedure çalıştıracağız // kayıt döneceği için ExecuteReader() kullanıp // DataReader'in bağlantı ile ilişkisini keselim Console.WriteLine(" // sadece tek değer döndürecek bir sql sorgusu // Bağlantıyı (kesinlikle) kapatalım. } |
|
Komut satırından derleme komutu:
| csc /reference:System.dll,System.Data.dll SqlCommandDeneme.cs |
Ve görünen:
width="297" />
Bitirirken...
Bu yazıda, ADO.NET'in hayati bileşenlerinden Command nesnesini inceledik.
Örneklerimizi SQL Server .NET sağlayıcısı tarafından sunulan nesneler üzerinde
verdik. Kodların ufak değişikliklerle OLE DB sağlayıcısının nesnelerine uyarlanmasını
da size bıraktık. Bundan sonraki durağımız DataReader nesnesi olacak.
İyi çalışmalar.
Connection (Bağlantı) Nesnesi
ADO.NET''in programcıya sunduğu veri erişim mimarisinden
ADO.NET başlıklı yazımızda bahsetmiştik. Belirttiğimiz gibi, ADO.NET,
bağlantısız veri operasyonlarına ve verinin standart XML ifadesine tam destek
veriyor.
ADO.NET''in veri kaynağıyla canlı ilişkide olan tarafını .NET
Veri Sağlayıcısı oluşturuyor. Bu sağlayıcı, veri kaynağına gönderilecek her
türlü komut, ve ondan dönecek her türlü yanıt için bir köprü vazifesi görüyor.
Tüm bu operasyonlar için, bu sağlayıcının aktif bir bağlantısı olması gerekiyor.
İşte bu bağlantı, Connection nesnesiyle temsil ediliyor. Connection
nesnesi, ADO.NET''in en temel nesnesi.
Her veri sağlayıcısı, kendine özgü
gerçeklenmiş bir bağlantı nesnesi sunmak durumunda. .NET ile gelen OLE DB .NET
sağlayıcısının sunduğu bağlantı nesnesi
bağlantı nesnesi ise
olarak aynı. Yazımızda her iki sağlayıcı için de bağlantı örnekleri vereceğiz.
SqlConnection
Microsoft SQL Server 7.0 ve üst
sürüm veritabanlarına erişmek için
nesnesi (daha doğrusu nesneyi sunan sağlayıcı), sadece SQL Server için
tasarlandığı için başka bir veritabanı erişiminde kullanamıyoruz. SQL
Server''in daha alt sürümlerine erişim içinse eskiden olduğu gibi yine OLE DB
kullanılacak. Peki 7 ve üst versiyonlarında neden ayrı bir sağlayıcı kullanmamız
gerekiyor? Aslında böyle bi zorunluluk yok. OLE DB hala bir seçenek. Ancak
veritabanı erişimi gibi masraflı bir işte daha yüksek performans
arzuluyorsak, tercihimiz SQL Server .NET veri sağlayıcısı olmalıdır. Çünkü bu
sağlayıcı, SQL Server ile TDS (Tabular Data Stream) paketleri
seviyesinde, yani SQL Server''in anladığı dilde haberleşiyor. Böylece OLE
DB gibi bir tercümanı direk saf dışı bırakmış oluyorsunuz. .NET
dokumantasyonunda bu durum şöyle çizilmiş:
Uygulamanızı hâlâ
veritabanından bağımsız yapmak istiyorsanız, çok katmanlı mimariyi iyi
planlamalı ve gerçeklemelisiniz. Veya ilerde konularımız arasında olacak
yazılmış arabirimlerden (IDbConnection, IDbCommand, IDataReader, ..) yararlanmak
da bir çözüm olacaktır.
Şimdi SQL Server 2000 üzerindeki ünlü
Northwind veritabanına bağlantı kuracağımız, bir konsol uygulaması
yazalım:
| SqlConnectionOrnegi.cs | |
// SQL Provider''i System.Data.SqlClient aduzayı temsil ediyor. using System.Data.SqlClient; namespace Evcil.NET { public class CBaglanti { public Main() { // bağlantı cümlesini oluşturalım. // OLEDB bağlantı cümlelerinden farklı olarak, // Provider değeri belirtilmediğine dikkat edin string sBaglantiCumlesi = "Server=(local); User id=sa; Password=; Database=Northwind"; // SqlConnection tipindeki bağlantı nesnemizi, alan // yapılandırıcısı (constructor) ile oluşturuyoruz. SqlConnection oConn = new SqlConnection(sBaglantiCumlesi); // bağlantımızın kurulması oConn.Open(); Console.WriteLine( varsayalım. // işimiz bitince bağlantıyı "kesinlikle" kapatmalıyız. oConn.Close(); Console.WriteLine( kesildi"); } } } | |
Neler
yaptığımıza biraz daha yakından bakalım. Başlangıçta, konsola yazı yazmak için
gereken
derleyiciye
yapmasak da olur; ama o zaman bahsedilen sınıfları, her seferinde aduzayı ile
birlikte (Fully-Qualified) yazmak zorunda kalırız:
kolayınıza(!) geliyor?
Kendimize has bir aduzayı ve sınıf tanımı
yaptıktan sonra, bağlantı denememizi, bağımsız (stand-alone)
uygulamamızın giriş noktası (entry point) olacak
Cümlesi" diye bir kavram görüyoruz. Bağlantı cümlesi, OLE DB''den gelen bi
kavramdır. Bir OLE DB sağlayıcısı üzerinden bir veritabanına erişimle ilgili her
türlü detay, daha genel bir ifadeyle bir "bağlantı" ile ilgili her detay
bağlantı cümlesinde ifade edilir. Bu cümle anahtar/değer çiftlerinin (;) noktalı
virgül ile birleştirilmiş halidir. İşte örnek bir bağlantı cümlesi:
Security=SSPI;Persist Security Info=False;Initial Catalog=Northwind;Data Source=127.0.0.1 |
Siz
de kolayca bir OLE DB bağlantı cümlesi oluşturmak isterseniz boş bir metin
dosyasının uzantısını .udl yapın. Dosyanın simgesinin değiştiğini
göreceksiniz. Dosyayı çift tıkladığınızda, "Data Link Properties"
başlıklı sihirbaza benzer bir Windows uygulaması açılacak. Burdaki seçenekleri
kullanarak geçerli bir bağlantı cümlesi oluşturursanız önünüze bir seçenek daha
çıkar: OLEDB bağlantısında, parametre olarak bağlantı cümlesi yerine bu dosyanın
yolunu verebilirsiniz. Böylece bağlantı detayınızı harici bir dosyada saklamış
olursunuz. Ne kadar faydalı olduğu tartışmalıdır.
Şimdi,
dikkat etmemiz gereken bir nokta var, ondan bahsedelim. Yukarıda verdiğim
bağlantı cümlesi örneği OLE DB içindi. OLE DB bağlantı cümlelerinde
gerekiyor. Eğer yapmazsak varsayılan sağlayıcı olan "OLE DB Provider for ODBC
Drivers" i seçmiş oluyoruz. Bu tür bir seçim yapmamızın nedeni OLE DB API
katmanının birbirinden çok farklı veri kaynaklarına erişimi mümkün kılması.
Bunun için de, bizden bağlanacağımız veri kaynağına uygun bir Provider
(sağlayıcı) seçmemizi bekliyor. Ancak
oluşturacağımız cümlede
SQL Server''e bağlanacağız ve bir "Provider" seçimi yapma hakkımız
yok.
Bağlantı cümlesinde anahtarların sırası önemli değildir. Geleneksel
olsun diye ilk önce
Source anahtarı da kullanılabilir.) Yerel SQL Server''e bağlanacaksak
anahtara
SQL Server''in IP adresini de yazabiliriz. Daha sonra SQL Server Login
bilgilerimizi belirtiyoruz. SQL Server''a iki türlü login olabiliriz. Birincisi
SQL Server Doğrulaması ile. İnternet uygulamaları için en uygun olanı
budur. Bu tür girişte bir kullanıcı adı ve parola belirtiriz. İkincisi ise
Bütünleşik Windows Doğrulaması''dır. Bu seçenekte ise, SQL Server
Windows''a giriş yaptığımız login bilgisine göre doğrulama yapar. Bağlantı
cümlesinde entegre Windows doğrulamasını kullanmak istersek user id ve password
anahtarları yerine
belirtmeliyiz. (veya "Trusted Connection = True;")
Sonra SQL Server
üzerindeki veritabanlarından birini seçmek istiyoruz. Bunun için de
bağlantı ile ilgili detayları verdiğimiz bir cümleyi oluşturmuş olduk. Bunu bir
string değişkene atadık.
yapılandırıcısı ile yarattığımız nesneye bağladık. Bağlantı cümlesini, nesneye
daha sonra da atayabilirdik ama kolaylık olsun diye, daha yapılandırıcıda iken
bu işi hallettik.
alabilecekleri değerler ile ilgili ayrıntılı açıklamayı lokal .NET Framework SDK
dokumantasyonunda veya href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemDataSqlClientSqlConnectionClassConnectionStringTopic.asp"
target=_blank>burada bulabilirsiniz.
Bağlantı nesnemizi
oluşturduk. Hafızada (heap''te) bu nesne için bir yer ayrıldı. Ancak tüm bunlar,
"bağlantı cümlesinde" bahsini geçtiğimiz SQL Server veritabanı ile fiziksel bir
bağlantı kurmuş olduğumuz anlamına gelmiyor. Şimdilik sadece niyetlendik. Bu
bağlantının kurulması için bağlantı nesnemizin
bağlantınız kurulacak ve bağlantı nesnemizin
veri kaynağı ile oConn nesnesi üzerinden canlı bir bağlantımız vardır ve
sağlayıcının diğer nesneleri ile (SqlCommand, SqlDataReader, SqlDataAdapter) bu
canlı bağlantı üzerinden istediğimiz manipulasyon operasyonlarını
gerçekleştirebiliriz.
Bu yazımızda sadece bağlantı nesnesi üzerinde
odaklanmak istediğimiz için, hiç bir işlem yapmadan bağlantımızı kapatacağız. Bu
iş için de parametresiz basit bir metodumuz var:
için zahmetli) bir iş olduğundan, işimizi en kısa sürede halledip bekletmeden,
aktif bağlantıyı kapatmayı unutmamalıyız. Eğer bunu unutursak, bağlantımız belli
bir zaman aşımı süresi kadar açık kalacaktır.
Örnek uygulamayı aşağıdaki
komutu kullanarak derleyebilirsiniz.
C:>csc /r:System.dll,System.Data.dll SqlConnectionOrnegi.cs |
Ve
uygulamayı çalıştıralım:
Görüldüğü gibi bir SQL
Server veritabanına bağlantıyı kolayca kurabiliyoruz. Burada belki de üzerinde
durulması yerinde olacak bir konu var: Bağlantı cümlesinin yeri. Yazdığımız
örnekte bağlantı cümlesini hiç bir kaygı duymadan kodumuzun içine gömdük.
Bağlantı cümlesinde yapılacak bir değişiklik için (örneğin SQL Server''in
adresinin değişmesi durumunda) uygulamayı yeniden derleme ihtiyacı doğacağı
açıktır. Bağlantı cümlesini uygulamadan ayrı bir noktada tutmak hem merkezi bir
yönetim hem de esneklik sağlayacak. Elbette bunun düz metin dosyası olması, bir
güvenlik sıkıntısı da doğuracak. Ancak ASP.NET uygulamalarının yapılandırma
dosyaları
Çünkü bu yapılandırma dosyaları düz yazı dosyaları olmalarına rağmen ASP.NET
motoru tarafından ziyaretçilere sunulmuyor. Tıpkı
ulaşılabilir olması, dosya özellikle SQL Server login bilgisi içeriyorsa çok
riskli olacaktır.
OleDbConnection
sağlayıcısı üzerinden bir veri kaynağına bağlantı tesis etmemizi sağlar.
Kullanımı aynen yukarıda bahsettiğimiz
tekrar etmeyeceğiz. Yalnız bu tip bağlantıda, bağlantı cümlesini oluştururken,
hedef veri kaynağına uygun bir Provider seçmemiz gerekecektir. OLE DB
veri sağlayıcısını kullanarak, sistemde OLE DB sağlayıcısı bulunan her veri
kaynağına (SQL Server, Oracle, Access, Indexing Service) bağlanabiliriz.
Biz bir Access veritabanına bağlantı örneği verelim:
| OleDbConnection.cs | |
using System.Data.OleDb; namespace Evcil.NET { public class COleDb { public Main() { string sBagCumle = @ "; OleDbConnection oConn = new OleDbConnection(sBagCumle); { oConn.Open(); } ) { Console.WriteLine( e.Message ); } { oConn.Close(); } } } } | |
Yaptığımız
her şeyin
Namespace olarak
nokta daha var. Bağlantı cümlesinde bir Access veritabanının fiziksel yolunu
belirtiyoruz. Peki string ifadenin önündeki "
ilk karakterle beraber özel görevleri var. Bir fiziksel yol yazarken normal "
kolaylık olarak sunulmuş bize.
Kodda, bağlantıda herhangi bir istisna
çıktığı durumda, istisnanın yakalanması ve her hâlukarda bağlantının kapatılması
için
olduk.
Bitirirken...
Bu
yazıda, veri kaynağı ile sağlayıcı üzerinden nasıl ilişki kurabileceğimizi
gördük. Bu veri tabanı operasyonları için ilk adımdı. Bundan sonra atacağımız
tüm adımlar, kurduğumuz bu ilişki üzerinden yürüyecek.
İyi çalışmalar.
.NET’te Veri Erişimi : ADO.NET
Her şey gibi ADO da büyük evrimden (veya hafif devrimden)
nasibini aldı. DAO ve ADO derken şimdi ADO.NET''le yüzyüzeyiz.
Microsoft''un veri erişimi için sunduğu yeni ara katman olan ADO.NET, bir çok
heyecan verici yenilikle geliyor. Yazımızda ADO.NET''i ve getirilerini aktarmaya
çalışacağız.
ASP veya VB ile uğraşanlar ADO''yu çok iyi biliyorlar.
.NET''e kadar, veritabanlarına, veri yığınlarına erişim için uygulama
geliştiricilerin kullandığı en yeni ara katman ADO (ActiveX Data Objects)
idi. ADO, gerçekten işleri çok basitleştirmişti. Her türlü veritabanı erişimi
için aynı nesne setini kullanmak, veritabanı ile ilgili detayın sadece bir
bağlantı cümlesine hapsedilmesi ADO''nun çarpıcı özellikleriydi. ADO, Windows
bünyesine yüklenen bir COM bileşeni idi. Gayet anlaşılır nesne modeli ile bizi
OLEDB sağlayıcıları ve ODBC sürücülerinin daha karmaşık olan
modelinden uzak tutarak, kolayca veritabanı operasyonları yapmamızı mümkün
kılıyordu.
Artık karşımızda yepyeni bir veri erişim servisi var:
ADO.NET. ADO.NET, sonuna eklenen "nokta net" ten gayet iyi
anlaşılacağı gibi .NET bünyesinde bir teknoloji. Yani .NET uygulaması geliştiren
bir programcının veriye erişmek için kullandığı her şey ADO.NET''in parçası
olacak. ADO.NET, Framework sınıf kütüphanesinde çeşitli aduzaylarından ve
bunlara bağlı düzinelerce sınıftan oluşan bir alt set.
ADO.NET elbette
ki ADO''nun kullanımında yaşanan güçlüklere çözüm getiriyor ve bunun yanında eski
nesne modelini de kısmen koruyor. Kısaca bakalım:
* ADO.NET,
veriyi XML ile içiçe bir yapıda ifade ediyor. Bu yeni yapının adı
DataSet. Bir dataset standart XML formatında ifade edilebiliyor. Tersi de
aynı derecede kolay bir işlem. ADO''da XML desteği kısıtlı düzeydeydi.
*
ADO ile genelde veri operasyonları aktif bir bağlantı üzerinden gerçekleşirdi.
Şimdi ADO.NET bağlantısız operasyonlara tam destek veriyor. Verilerle
işinizi, veri kaynağına en az seviyede erişerek halledebiliyorsunuz. Bu
kabiliyet, yine DataSet nesnesi üzerinde. Tüm bunlar ADO.NET''in kalbinin DataSet
nesnesi olduğunu anlatmaya yetiyor.
* ADO da veritabanı bağlantıları
OLEDB sağlayıcıları üzerinden gerçekleşiyordu. Bir Access veritabanına bağlanmak
da, bir SQL Server veritabanına bağlanmak da aynı köprüden geçmemizi
gerektiriyordu. Şimdi ADO.NET, SQL Server''le direk konuşabilen bir nesne
topluluğuna sahip. OLEDB ile klasik bağlantı şansınız devam ederken, size
iyilenmiş bir SQL Server erişimi de sunuluyor.
Veri sağlayıcıları biraz
açalım.
Sağlayıcıları
Sağlayıcılar, veri kaynaklarına bağlantı kurar, komut
icra ettirir, onlardan sonuç setleri getirirler. Kısaca veri kaynağı ile
uygulamanız arasında bir köprüdür. (.NET veri sağlayıcılarına, Managed Data
Providers da denilmektedir.)
.NET, bünyesinde iki tane sağlayıcı ile
geliyor: OLEDB .NET Veri Sağlayıcısı ve SQL Server .NET Veri
Sağlayıcısı. İlkinin bildiğimiz OLEDB''nin .NET uyarlaması olduğu belli. Asıl
dikkat çekici olan ikincisi. Bu sağlayıcı Microsoft SQL Server 7 ve üst
sürümleri için optimize edilmiş. Microsoft, SQL Server 7 ve yukarısıyla
çalışacaksanız bu sağlayıcıyı kullanmanızı öneriyor. Zira bu sağlayıcı, SQL
Server ile en alt seviyede, yani TDS (Tabular Data Stream) protokolüyle
konuşuyor. Bu da size performans kazancı olarak dönüyor. Bir sevindirici haber
de geçen haftalarda geldi. Artık Oracle veritabanları için de spesifik
bir .NET sağlayıcısı mevcut.
OLEDB''nin çıkışıyla geri plana çekilen
ODBC (Open Data Base Connectivity) teknolojisinin akıbetini merak edenler
yok mu? Microsoft, ODBC için de bir .NET sağlayıcısı yazdı. Ama bu .NET''in
standart sağlayıcıları arasında gelmiyor. Ayrıca edinmeniz gerekiyor.
(http://msdn.microsoft.com/downloads)
Bilmemiz gereken bir başka önemli
nokta da, her veri sağlayıcısının Framework sınıf kütüphanesinde farklı
aduzayları (namespace) ile temsil ediliyor oluşu. OLEDB sağlayıcısı için
ile ilgili temel sınıfların da
Mimarisi
ADO.NET mimarisini ikiye ayırarak incelemek gerekiyor. Biri
bağlantılı, diğeri bağlantısız taraf. Bağlantılı taraf, bir .NET
veri sağlayıcısının üzerinden yapılan bağlantıyla çalışan nesneleri içeriyor.
ortak özelliği, aktif bir bağlantıya ihtiyaç duymaları. Diğer tarafta,
bağlantısız bir yapı var:
olarak tasarlanan bir nesne. Hafızada duran ve istendiğinde XML olarak kalıcı
hale getirilebilen ilişkisel bir veritabanı olarak düşünebilirsiniz. Zira
DataSet, birden fazla tablolar içerebiliyor; bu tablolar arası ilişkiler,
kısıtlamalar, görünümler tanımlamanıza olanak veriyor.
Bu mimariyi en
iyi, dokümantasyondan aldığım aşağıdaki diyagram özetleyecek:
Görüldüğü gibi,
bağlantısız veriyi ifade eden DataSet nesnesi, bağlantılı tarafa DataAdapter
nesnesiyle ulaşıyor. Ve bir DataSet, tek metodla disk üzerinde bir XML
dosyasında saklanabilecek veya bir XML dosyasından vücut bulabilecek esneklikte.
.NET''in XML desteği had safhada olan
veri erişim mimarisine verdiği isim ADO.NET. Bu mimari, Framework sınıf
kütüphanesinde bir çok aduzayı ve düzinelerce sınıfla temsil ediliyor. ADO.NET,
eski versiyonu ADO''dan farklı olarak bağlantısız veri operasyonlarına tam destek
veriyor. Bu iş için DataSet adında iddialı bir nesnesi var.
Bu
yazımızda, ADO.NET''i konsept düzeyinde anlatmaya çalıştık. İlerleyen haftalarda,
tek tek bu mimariyi oluşturan nesneleri, uygulama örnekleriyle beraber
işleyeceğiz.
İyi çalışmalar.
ASP.NET ile E-Mail Gönderme
Klasik ASP 'nin ayrıntı denebilecek bazı işleri yapabilmesi için
bileşenlere ihtiyaç duyulmasından hep şikayet edilir. Hatta birçok kişi ASP 'nin
en kötü yanının bu olduğunu düşünür. ASP ile e-mail göndermek için server'da
gerekli bileşenlerden en az birisinin yüklü bulunması gerekir.
ASP
kaynak sitelerinin ve böylece ASP kullanımının artmasıyla birlikte bedava ASP
destekli bulundurma hizmeti veren siteler açılmaya başladı. Ancak bunlar bedava
oldukları için bazı özelliklerden yoksunlar. Bazılarına FTP ile bağlanamazken,
bazılarında bulunan sitelere ulaşmak mümkün olmuyor. Çoğunda ise herhangi bir
mail bileşeni yok. Yani bedava ASP bulundurma sitesinden hesabı bulunan kişiler
e-mail gönderemiyorlar.
ASP.NET 'te durum böyle değil. E-mail göndermek
için ayrı bir bileşene ihtiyaç yok. ASP.NET ile site yapan herkes iletişim
sayfasında e-mail adresini vermekle yetinmeyip mail formunu da hazırlayabilir.
Peki nasıl ?
Şimdiye kadar ki örneklerde herhangi bir namespace
(isimuzayı) 'e ihtiyaç duymadık. Code-behind özelliğini kullanmadığımız için web
kontrolü kullanacağımızda System.Web.UI.WebControls namespace 'ini sayfamıza
dahil etmemiz gerekmedi. Ancak bu sefer buna gerek duyuyoruz. Mail göndermek
için gerekli namespace 'i "Import" direktifini kullanarak sayfamıza dahil
edeceğiz. Bu namespace System.Web.Mail, CDOSYS (Collaboration Data
Objects for Windows 2000) bileşenini kullanarak mail göndermemize olanak
verir.
%> <%@ Import Namespace="System.Web.Mail" %> |
System.Web.Mail
namespace 'i içerisindeki MailMessage ve SmtpMail sınıflarını
kullanacağız. MailMessage sınıfının özelliklerini kullanarak gönderilecek adres,
konu ve mesaj gibi içeriği oluşturan elemanları belirleyeceğiz. SmtpMail
sınıfıyla ise maili göndereceğiz.
width=399>
Önce ziyaretçinin bilgi
girişi yapacağı formu hazırlıyoruz. Bu form gönderen kişinin e-mail adresinin,
e-mailin konusunun ve mesajın yazılacağı birkaç TextBox kontrolünden ve tabii ki
bir Button kontrolünden oluşacak. Script etiketleri içerisinde MailGonder isimli
bir sub oluşturuyor ve Button kontrolünün OnClick özelliğine bu sub 'ın ismini
yazıyoruz. Şimdi MailGonder 'in içerisinde bulunması gereken kodlara sıra geldi.
Sub MailGonder(Sender As Object, E As EventArgs) Dim YeniMail As New MailMessage() YeniMail.From = txtKimden.text YeniMail.To YeniMail.Subject YeniMail.Body = txtMesaj.text SmtpMail.SmtpServer = SmtpMail.Send(YeniMail) Response.Write( Response. End </ |
MailGonder
sub 'ında ilk olarak türü MailMessage olan yeni bir nesne oluşturuyoruz.
Ardından bu nesnenin From (Kimden), Subject (Konu) ve Body
(Mesaj) özelliklerine hazırladığımız bilgi giriş formundaki kontrollerin
değerlerini atıyoruz. To (Kime) özelliğine değeri direk atıyoruz. Çünkü
e-mail formuyla sadece bu adrese e-mail gönderilebilmesini istediğimizi
farzediyorum
Daha sonra SmtpMail.SmtpServer özelliğini kullanarak
e-maili gönderirken kullanılacak olan mail server 'ın adresini belirliyoruz. Son
aşama ise e-mailin gönderilmesi.. SmtpMail sınıfının Send yöntemine,
e-mail mesajının içeriğini oluşturmak için kullandığımız YeniMail 'i parametre
olarak yolluyoruz. Ve e-mail gönderiliyor. Hepsi bu kadar..
| Sayfanın tüm kodu | |
%> <%@ Import Namespace="System.Web.Mail" %> Sub MailGonder(Sender As Object, E As EventArgs) Dim YeniMail As New MailMessage() YeniMail.From = txtKimden.text YeniMail.To YeniMail.Subject YeniMail.Body = txtMesaj.text SmtpMail.SmtpServer = SmtpMail.Send(YeniMail) Response.Write( Response. End </ style="font: 11px verdana;"> Kimden :< < width= Konu : < width= Mesaj : < TextMode= < text= | |
Gördüğünüz
gibi ASP.NET ile e-mail göndermek çok kolay ve ayrıca birşeye ihtiyaç duyulmadan
yapılabiliyor. Gerekli olan tek şey ASP.NET desteği veren bir bulundurma
hesabınızın bulunması diyebiliriz. Peki HTML veya Text e-mail
gönderme seçenekleri yok mu ? Tabii ki var ancak bunlar daha ileriki yazıların
konusu olacak. Bu makalede en basit haliyle e-mail gönderdik. Ayrıntıları
ileride.. Görüşmek üzere..
Validation Kontrolleri
Kompleks web sitelerinin birçoğunda üyelik sistemi veya forum gibi server-client
arasında iletişim kurulmasını gerektiren uygulamalar vardır. ASP ve PHP gibi
server taraflı platformların kullanımının yaygınlık kazanmasından sonra birçok
web sitesi üyelik sistemi kullanmaya başlamış, sadece üyelerin ulaşabildiği
forum gibi uygulamaları sunmuştur. Kaynak sitelerin artmasıyla birlikte, birkaç
yıl önce örnekleri sadece alışveriş siteleri gibi büyük projelerde görülebilen
üyelik başvurusu formları, bir nevi özelleşmiş ve herkesin kullanmaya başladığı
bir uygulama olmuştur.
Bedava ASP veya PHP hosting hizmeti veren web
sitelerinin de artışıyla birlikte her sitenin forumu ve böylece bir üye
topluluğu olmuştur. Birçok web programcısı değişik tarzlarda üyelik başvurusu
formları hazırlamıştır. Çoğu kez ziyaretçinin girdiği değerleri kontrol edip
uygunsuz üyelik başvurularının önüne geçmek büyük bir sorun oluşturmuştur.
Bazıları işin kolayına gidip kullanıcısına pek yardımcı olmayan formlar
hazırlamayı tercih etmişlerdir. User-friendly olmayan bu formlar beyaz ve boş
bir sayfada "Kullanıcı adınız 4 karakterden uzun olmalıdır" demekle
yetinmişlerdir. Özellikle bedava SMTP mail hizmeti veren, bu işe gerçekten para
yatırıp zaman harcayan Yahoo veya Hotmail benzeri sitelerin başvuru formları web
programcılarının hayallerini süslemiş ve hedefleri olmuştur.
Kullanıcısını anlamayan ve çıkan hataları tokat gibi yüzüne çarpan
formlar yerine daha arkadaşçıl formlar tercih edilmeye başlamıştır. Ancak Yahoo
veya Hotmail ''in sahip olduğu üye başvuru formunu yapmak da pek kolay değildir.
Birçok kişi bu uğurda uzun zaman harcamıştır. Çoğu ASP veya PHP ''nin
yetersizliğine bu sırada kanaat getirmiş, eskinin el üstünde tutulan
teknolojilerinin artık eskidiğini düşünmüşlerdir. Klasik ASP ile, hiçbir alanı
doldurulmadan gönderilen bir formu tekrar göstermek ve doldurulması gereken
input kutularının yanına kırmızı bir font ile hata yazısı yazmak kolay iş
değildir.
Bazı web programcıları ise daha ileri gidip bu kontrollerin
sayfa tekrar yüklenmeden yapılmasını istemiştir. Bunu istemek her ne kadar çok
kolay olsa da her şey o kadar kolay değildir. JavaScript ile birşeyler
yapılabilir belki ama bu uğurda günler harcanmıştır.
Kontrolleri
ASP.NET Server kontrollerinden birisi de Validation
(Geçerlilik) kontrolleridir. Server taraflı validation kontrolleri
onaylanması istenen veriyi kontrol edip gerekirse hata mesajı gösterir. Server
bu kontrollere gizli (invisible) kontroller olarak davranır. Kullanıcı
istenmeyen bir veri girişi yaptığında kontrol görünür (visible) olur.
6
çeşit validation kontrolü ASP.NET ile web programcısının kullanımına
sunulmuştur.
taşımadığını kontrol eder.
belirlediği regular expression ile karşılaştırıp kontrol eder.
değerini veya input kontrolünün değeri ile yine programcının belirlediği bir
değeri karşılaştırır.
olup olmadığını kontrol eder.
geliştirmenizi sağlar.
verir.
Validation kontrolleri görevlerini server tarafında olduğu gibi
client (istemci) tarafında da gerçekleştirirler. RequiredFieldValidator
dışındaki kontroller boş input kontrolünde uygunsuz bir durum bulamazlar. Bir
input kontrolü için birden fazla validation kontrolü kullanılabilir. Validation
kontrollerinin en yaygın kullanılacak olan birkaç özelliği şunlardır.
değerde uygunsuz bir durum olduğunda hata mesajı olarak gösterilir. Ayrıca
ValidationSummary''de de bu mesaj gösterilir.
kadar gizli beklerler. Kullanıcı veriyi girerken istenmeyen bir format
kullanmışsa hata mesajı gösterilir. Display özelliğinin üç muhtemel değeri
vardır.
alan başlangıçta ayrılır.
ayrılmaz ve gerektiğinde sayfanın diğer içeriği ile yer değiştirilerek
gösterilir.
mesajı gösterilmez. Mesaj özette gösterilir.
RequiredFieldValidator
adından da anlaşılabileceği gibi girilmesi zorunlu tutulan input kontrollerini
denetlemek için kullanılır. Kontrolün bu görevi yerine getirebilmesi için
denetleyeceği kontrolün id ''sini bilmesi yeterlidir. Boş bir input kontrolü
RequiredFieldValidator gözünde hatalıdır. Kullanımı şu şekilde yapılır:
| RequiredFieldValidator | |
runat="server" ControlToValidate="txtParola" ErrorMessage="Parolayı girmelisiniz" Display= | |
RequiredFieldValidator
kontrolüne denetleyeceği kontrolün id ''si ControlToValidate özelliği ile
gösterilir.
VBScript ''in son
sürümüyle birlikte klasik ASP programcılarının da kullanmaya başladığı
RegularExpression bu kontrolün ana bileşenini oluşturur.
ControlToValidate özelliğinde id ''si verilen input kontrolünün değeri
ValidationExpression özelliğinde verilen regular expression ifadesi ile
karşılaştırılır. RegularExpressionValidator gerekli ifade oluşturulursa diğer
bazı validation kontrollerinin görevini yapabilir. Örneğin bir kontrolün
değerinin olup olmadığını kontrol edebilir.
| RegularExpressionValidator | |
runat="server" Display= ErrorMessage= ValidationExpression= | |
Bu
RegularExpressionValidator kontrolündeki regular expression ifadesine göre
txtParola kontrolünün değeri en az 4, en fazla 8 karakter olabilir. Aksi
durumlarda hata mesajı gösterilir.
Bu kontrol değişik şekillerde
kullanılabilir. Bir kontrolün değeri ile başka bir kontrolün değerini
karşılaştırabileceğiniz gibi bir kontrolün değeri ile spesifik (belirli) bir
değeri de karşılaştırabilirsiniz. Ayrıca kontrolün değerinin belirli bir veri
tipinde olup olmadığını da denetleyebilirsiniz.
İki kontrolün değerini
karşılaştırmak için ControlToValidate ile birlikte ControlToCompare
özelliği de kullanılır. İki değer aynı değilse hata mesajı gösterilir.
| İki kontrolün değerini karşılaştırma | |
id="cvParola" runat= ControlToValidate= ErrorMessage= olmalıdır"/> | |
Bir
kontrol ile özel bir değeri karşılaştırmak içinse ValueToCompare özelliği
kullanılır.
| Kontrolün değeri ile özel bir değeri karşılaştırma | |
id="cvParola" runat= ControlToValidate= ErrorMessage= girdiniz"/> | |
Gördüğünüz
gibi txtParola kontrolünün değeri ile ValueToCompare özelliğinin değerini bu
kontrol ile karşılaştırabiliyoruz. Ben size örnek vermek için parola denetlemesi
yapan bir CompareValidator kullandım ama programcının belirleyeceği parola
kaynak kodda görüneceği için pek güvenilir bir yöntem olmaz. Nasıl
kullanacağınız size bağlı..
| Kontrolün değerinin veri türünü denetleme | |
id="cvParola" runat= ControlToValidate= ErrorMessage= Operator="DataTypeCheck" Type= | |
Bu
CompareValidator kontrolü txtParola kontrolünün değerinin "Integer" türünde
olmasını ister. CompareValidator bu denetlemeyi txtParola ''nın değerini Type
özelliğinde belirtilen veri türüne dönüştürmeyi deneyerek yapar. txtParola ''ya
girilen değer "Integer" ''e dönüştürülemiyorsa "InValid" (uygunsuz) bir durum söz
konusu olduğuna karar verilir ve hata gösterilir. Ayrıca Operator özelliğine
DataTypeCheck değeri verilerek veri türü kontrolü yapılmak istendiği
belirtilir.
RangeValidator ile denetlenen
kontrolün değerinin belli bir aralıkta olup olmadığı kontrol edilir.
MinimumValue ve MaximumValue özellikleri ile değerin hangi sayı
aralığında olabileceği belirtilir.
| RangeValidator | |
id="rvNumara" runat= ControlToValidate= MinimumValue="2" MaximumValue= | |
ASP.NET ''in web programcısına
sunduğu validation kontrolleri yetersiz kaldığında CustomValidator imdata koşar.
CustomValidator ''ın görevi programcı tarafında yazılan bir sub routine (alt
program) ile verilir. Denetlemenin sonucu da sub routine içerisinde belirtilir.
| CustomValidator | |
language="vb"> Sub ParolayıKontrolEt(Sender As "sifre" then E.IsValid = True E.IsValid = False end End Sub </ < runat= id="cvParola" runat= ControlToValidate= OnServerValidate= < | |
CustomValidator
kontrolüne ControlToValidate özelliğinde denetlenecek input kontrolünün id ''si
verilir. OnServerValidate özelliğine ise denetlemeyi yapacak sub routine
''in ismi yazılır. Bu sub iki parametre alır ve ikinci parametre
ServerValidateEventArgs sınıfının bir örneğidir. Bu nesne ile denetlemeyi
yapan validator kontrolünün özelliklerine ve yöntemlerine ulaşılabilir. If
kontrolüyle birlikte validator kontrolü "valid" veya "invalid" yapılır.
Her ne kadar CustomValidator kontrolü işini server tarafında yapacak
olsa da, ASP.NET otomatik olarak denetleme işini yapacak JavaScript kodunu
yazar. Bu kodların görünmesini engelleyecek ve böylece güvenliği bir kademe
artırabilecek seçenekler detaya girdiği için daha ileride yer vereceğim.
src="/cgi-bin/files/2002082_ornek6.gif" width=509>
Validation
(Geçerlilik) kontrolleri web programcılarının veriyi kontrol etmesini
kolaylaştırıyor. Her türlü veri giriş formunun doldurulmasında ziyaretçinin
bilerek/bilmeyerek yanlış formatta bilgi girmesi bu yolla engellenebiliyor.
Klasik ASP ''de bu iş için uzun süre harcanıp karmaşık kodlar yazılırken ASP.NET
ile birlikte bu işkence ortadan kalkıyor.
input kontrolünün değerinin geçerli olmadığını düşünürse, formun gönderilmesini
sağlayan buton pasifleşir. Tıklanabilir ama görevini yapamaz. Tüm alanlar
geçerli olduğunda buton yeniden aktif olur.
RequiredFieldValidator, RegularExpressionValidator,
RangeValidator, CompareValidator ve CustomValidator bu makalemizin konusunu
oluşturdu. Server taraflı CustomValidator örneği kullanarak basit bir örnek
yaptım. Client (istemci) taraflı CustomValidator örneğini ise başka bir yazıda
vereceğim. Ayrıca diğer bir validation kontrolü olan ValidationSummary
hakkında da başka bir yazıda bahsedeceğim.