State Management - 3

Merhaba herkese. State Management makale dizimizin 3 bölümü ile birlikteyiz.

Çok kısa diğer makaleleri hatırlatacak olursak: 1. makalede State Management kavramını ve ViewState nesnesini; 2. makalede ise Cookie nesnesini incelemiştik. Şimdi de sırada QueryStrings var.

QueryStrings:

Query String dediğimiz şey, aslında çoğumuzun sürekli karşılaştığı bir nesnedir. Query Stringler, URL'lerin sonunda gördüğümüz bilgilerdir. URL'nin sonunda ne var, hangisi query string? Somut bir örnekle bu konuyu daha yakından inceleyelim.

Diyelim ki bir şeyler sipariş etmek için "Yemek Sepeti"ne girdiniz(www.yemeksepeti.com). Bu bir URL(Uniform Resource Locator)'dir. Sayfada İstanbul'u seçtiğinizde adres çubuğundaki URL http://www.yemeksepeti.com/index.asp?city=215 şekline dönüşüyor. Malumunuz index.aspx, default.asp vs. ana sayfayı gösterir. İşte ? işareti query stringimizi başlatmış oluyor. Bu yüzden yukarıda karşılaştığımız nesnedir diye bir ifade kullandım. City diye bir özellik var ve bu özelliğe 215 değeri verilmiş. Gördüğünüz gibi çok basit bir şekilde durum bilgisini tutmuş.

Son bir örnek daha, Google'da bir şey aratınız diyelim. Ben "Beşiktaş"ımı arattım. http://www.google.com.tr/search?hl=tr&q=Be%FEikta%FE&btnG=Google%27da+Ara&meta= şeklinde bir link yazıldı adres çubuğuna. Linkte geçen hl=tr yerine hl=en yazdığınızda Google'ın İngilizce sayfasına yönlendiğinizi göreceksiniz. q'nun(query; yani sorgulattığınız, arattığınız kelime) karşılığı olarak da başka bir şey yazıp aratabilirsiniz.

Query Stringlerde sayfa oluşurken dışarıden parametre yolluyoruz. URL yoluyla veriyi mevcut sayfaya veya başka bir sayfaya taşıyoruz.
Avantajları
1. Herhangi bir server kaynağına ihtiyaç yoktur. Direkt URL üzerinden taşıma yapılıyor.
2. Tüm tarayıcıların desteklemesi.
3. Kolay uygulanabilir olması.
Dezavantajları
1. Güvensiz olması. Gördüğünüz gibi açık seçik kullanıcının gözü önünde her şey. Ayrıca query stringe yazdığınız şey direkt sorguya gidiyor.
2. Kapasite sınırı. Bazı tarayıcıların, URL'lere 2083 karaktere kadar izin verdiği belirtiliyor.

Query Stringlerde, sayfa aynı ancak içerik query string değerine göre değişiyor. Bu sebepten aynı sayfadan istekte bulunurken kullanmak mantıklıdır. Bunun da iyice anlaşılması için örnek ile açıklayayım. Diyelim ki bir türlü yayınlamadığım sayfamı yayınladım ve resimler ekledim. :) www.gurkanalkan.com/galeri/sacmaresimler.aspx?resim=1 diye bir sayfada resim çıkmış olsun. Siz "ileri"ye bastığınızda bunun www.gurkanalkan.com/galeri/ sacmaresimler.aspx ?resim=2 haline geldiğini gördünüz. Burada resim değişti. Bakın sayfa aynı. Siz, "sonraki resim" seçeneğine tıklayarak bana dışarıdan parametre veriyorsunuz aslında. 2 numaralı resmi istediniz. Ben de size sadece oradaki resim yerine 2 numaralı resmi verdim. Yani değişen şey resimdir. Herhalde anlaşılmıştır bu nokta da.

Arkadaşlar biraz daha ilerlemeden önce bir şeyi belirtmek istiyorum. Verdiğim örnekler hep bir özellike ve değer içeriyordu. Böyle bir kısıtlama yok. Asıl kısıtlamanın tarayıcıdan kaynaklı 2083 karakter olduğunu belirtmiştik. Yani siz birden çok özellik ve değer kullanabilirsiniz. Örneğin; https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false şeklinde devam eden google sayfası. Böyle birden çok özellik söz konusu olduğunda & ile ayırıyoruz.

İsterseniz küçük bir örnek yapalım. Bir web projesi açalım. Adı Default.aspx olarak kalsın. İşlemlerimizi hızlı yapmak için Design ekranına bir adet TextBox ve bir adet de Button koyalım. Ardından 2. bir sayfa ekleyelim projemize. Onun da adı Default2.aspx olarak kalsın.

İlk sayfamıza (Default.aspx) koyduğumuz Button'a basınca, TextBox'a yazmış olduğumuz değeri Default2.aspx saysına taşıyalım.

protected void Button1_Click(object sender, EventArgs e)
{
Response.Redirect("Default2.aspx?isim="+TextBox1.Text);
}

Yukarıda gördüğünüz gibi Button'a basınca sayfamızı Default2.aspx'e yönlendir dedik, ancak isim adlı özellik(query string'de özellik dediğimizi hatırlayın) ve değer olarak da TextBox'ta yazan değer ile birlikte gidecek.
Default2.aspx sayfasında da aşağıdaki gibi bir kod yazalım.
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Request.QueryString.Get("isim"));
}

Query String ile taşıdığımız değeri sayfaya yazdırmış olduk. Query Stringler kullanıcılar tarafından belirlenen ifadelerdir. Yani query stringleri kullanıcı gönderir. Bu yüzden query string okurken Request'i kullanıyoruz. Request.QueryString.Get deyip parametresine querystring'in özelliğinin adını geçiyoruz.

Msdn'den baktıysanız ya da QueryString'in açıklamasına göz attıysanız:

public NameValueCollection QueryString { get; }

gibi bir ifade görmüşsünüzdür. Bu QueryString'in NameValueCollection (2.makalemizde de sıkça geçmişti.) türünden bir "property" olduğunu söylemektedir.
Bunula ilgili bir örnek yapacak olursak:

int loop1, loop2;

NameValueCollection coll=Request.QueryString;
String[] arr1 = coll.AllKeys;
for (loop1 = 0; loop1 <>
{
Response.Write("Key: " + Server.HtmlEncode(arr1[loop1]) + "
");
String[] arr2 = coll.GetValues(arr1[loop1]);
for (loop2 = 0; loop2 <>
{
Response.Write("Value " + loop2 + ": " + Server.HtmlEncode(arr2[loop2]) + "
");
}
}

State Management-2'yi okuyanlar için herhalde gayet açık bir koddur. Hatırlarsanız NameValueCollection'ın bir key- value çifti olduğundan bahsetmiştik. AllKeys property'si cookie'de değindiğimiz gibi bize string dizisi dönen bir özellikti. Yukarıdaki örnek kodda da önce anahtarları (bizim özellik diye bahsettiğimiz şey), bir string diziye atmış. Daha sonra döngüde değerleriyle birlikte bu anahtarları da yazdırıyoruz.

Query String'e girmişken bir konuya daha değinmek istiyorum: Server.Transfer

Server.Transfer, Response.Redirect ile benzer işleve sahiptir. Karşılaştırmalı bakalım isterseniz.
Response.Redirect deyince siz browser'a verilerinizi gönderiyorsunuz ve server'dan "request"te bulunup diğer sayafaya verileri taşıyorsunuz. Server.Transfer ile bunu yaptığınızda göze çarpan ilk fark URL'nin sabit kalmasıdır. Buna mukabil Query String de görünmemektedir.

İlk yaptığımız örnekte ButtonClick'teki Response.Redirect kodu yerine aşağıdaki satırı yazın ve tekrar çalıştırın.
Server.Transfer("Default2.aspx?isim="+TextBox1.Text, true);
Buttona tıkladıktan sonra aşağıdaki sayfanın URL adresine dikkat buyurun.

Server.Transfer kullanımındaki bir diğer farklılık, bu yöntemle server'ın kaynaklarının korunmasıdır. Bu yöntemle tek bir request ile işlerinizi yapabilmektesiniz. Response.Redirect kullanırken iki request yapıyorduk. Dolayısıyla Server.Transfer kullanmak server'ın performansı arttırdığı gibi, uygulamamızı da hızlandıracaktır. Ancak buradaki önemli nokta, Server.Transfer'deki transfer olayı aynı site içerisinde çalışmaktadır. Farklı bir alan için Response.Redirect kullanmak durumundasınız.

Server.Transfer'in dikkat ettiyseniz 2. bir parametresi var. Yukarıda kasıtlı olarak değinmedim. Bu parametre bool preserverForm. Bunu true yaparsanız, transferi yaptığınız sayafan da query sring ve form değişkenlerine erişebilirsiniz. WebForm1.aspx diye bir sayfanızdan WebForm2'ye transfer yapacaksınız diyelim. Ve WebForm1 sayfanızda TextBox1 adında bir textbox var olsun. WebForm2'den buna Request.Form("TextBox1") diyerek erişebilirsiniz.

Server.Transfer'de çıkabilecek bir sorun var: "The View State is invalid for this page and might be corrupted" diye bir hata almanız mümkün. Asp.Net'te varsayılan olarak EnableViewStateMac true olarak ayarlanmıştır. Bu özelliği State Management-1 makalemizde hatırlarsanız incelemiştik. Çok fazla detaya girmeyeceğim o yüzden. Bu özellik true iken MAC doğrulama mekanizması çalışıyordu. Server.Transfer dediğinizde bu Mac mekanizması devre dışı kalabiliyor. ViewState'in sayfalar arasında transfer edilemeyeceğini burada da hatırlatalım. Dolayısıyla MAC çalışamaz. Bunu aşmak için bu özelliği false yapmalısınız. (Daha sonra tekrar true yapabilirsiniz.)

Kısaca Smart 404 diye bilinen hata sayfalarına da değineceğim arkadaşlar. Query Stringlerin URL'de göründüğünü ve dışarıdan müdaheleye açık olduğunu sanırım anladınız. Kullanıcıların sitelerin güvenliği konusunda çok meraklı olduğunu göz önüne alırsak bu kötü bir durum. :) Eğer Query String'e olmayan ya da alfanümerik karakterlerden oluşan bir değer girilmişse kullanıcıları 404 durum kodlu hata sayfalarına yönlendirebilirsiniz. Ya da.. İşte ya da deyince akla Smart 404 geliyor. :) Böyle adlandırıldığı için bu ismi kullanıyorum ama adı kimsenin gözünü korkutmasın. Bu sayfalar, doğru girilmeyen query stringlerde kullanıcıya daha düzgün bilgiler verirler. Hatta bazıları daha da ileri giderek, kullanıcının girdiği query string'e yakın sonucu açar veyahut sonuçları listeler. Bunu uygulayan en önemli sitelerden birisi de www.amazon.com . Yanlış bir query verirseniz URL'sine: "Looking for something?
We're sorry. The Web address you entered is not a functioning page on our site" diye bir sayfa ile sizi karşılar. Bir süre önce de "Sorry, you didn't find what you are looking for. Did you mean ........?" deyip size alternatiflerinizi sıralardı. Ki web uygulamalarında hata sayfalarını yönetmenin ne kadar önemli olduğunu takdir edersiniz.

Böylelikle "Client-Based State Manegement"ı bitirdik arkadaşlar. Bundan sonraki makale ya da makalelerimizde Session ve Application'ı inceleyeceğiz.
Görüşmek üzere..

Gürkan Alkan
İstanbul Üniversitesi Bilgisayar Mühendisliği

Kaynaklar:
1. http://support.microsoft.com/default.aspx?id=kb;en-us;Q316920
2. http://www.developer.com/net/asp/article.php/3299641
3. http://msdn.microsoft.com/en-us/library/system.web.httprequest.querystring.aspx
4. http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx