evcil.net noktanın egemenliği

Bir ASP.NET MVC Deneyi

Hafta sonu sıkıldık diyelim. İşte güzel bir vakit geçirme teklifi. Bakalım ASP.NET MVC pişmiş mi bir tadına bakalım.

Teknoloji bıraktığımız yerde değil, mütemadiyen tekâmül ediyor. ASP.NET çıkınca çok ilgi göstermiştik. Şimdi bakıyoruz geriye, kaç sene oldu. Meraklısına yeni ortamlar lâzım. Sağolsun Microsoft'un ürünlerindeki bir sonraya bırakılmış çözümler bu beklentiyi her zaman sıcak tutuyor. ASP.NET için de öyle oldu denilebilir. Gelinen noktada, klasik ASP.NET ile geliştirmenin çoğu durumda isteneni karşılamadığı, mimâri olarak geliştiricinin önünü tıkadığı yüksek sesle konuşulur oldu. Bu sesler Microsoft tarafından da dinleniyordu muhakkak ve onlar da MVC yaklaşımını ASP.NET sisteminin içine gömdüler. Daha doğrusu gömecekler de prova yapıyorlar.

Bu yazımızda, çay-kahve-çorbamızı alıp şu yeni MVC ne menem bir şeymiş, ona eğileceğiz. Umarız, zevkli bir teknik yazı olur ve biz de memnuniyetle yayımlarız. Vira bismillah!

Girizgâh

MVC Nedir?

MVC sâir kereler yazıldığı gibi Model-View-Controller ifadesinin kısaltması olup daha çok web uygulamaları geliştirmede rehberlik edecek mimari bir kalıptır. Bir çok fikir gibi önce Java âleminde popüler olup sonra da .NET âlemine sıçrayanlardan birisi. Tekrara düşmemek için size birkaç link savurup MVC'ye giriş kısmını geçelim:

• Wikipedia'da MVC maddesi
• Vikipedi'de MVC maddesi
• Taner'in okulumuzun bahar etkinlikleri için hazırladığı MVC sunumu.

ASP.NET MVC Nedir?

Bu konuda da üç aydır oluşan bir bilgi birikimi mevcut. Hâzır olanı kullanmak programlamadaki temel prensiplerimizden biriyken, neden bunu yazı yazarken kullanmayalım. Hadi size birkaç link daha:

• ASP.NET MVC ve Düşündürdükleri
• İlk ASP.NET MVC Kod Örnekleri
• Scott'un ASP.NET MVC serisinin ilki.

Deney İçin Hazırlık

• Makinenize ücretsiz dağıtılan Visual Web Developer 2008 Express Edition'ı (VWD) kurun. Şimdi sizi masrafa sokmayalım Visual Studio 2008 Team Suite kurdurup.
• Yukarıdaki kurulumun üzerine geçenlerde duyurulan ASP.NET 3.5 Extensions kurulumunu geçin.

İşlem tamam demektir. VWD 2008'i açıp "New Site" dediğinizde aşağıdaki manzara var ise oturup üzerinden konuşabiliriz demektir :

Projeyi Oluşturmak

VWD'den yeni bir "ASP.NET 3.5 Extensions Web Site" açmamız lâzım. İlk açılışında pek bir malzeme olmuyor projede. Default.aspx ve web.config var; az ve öz. Biz default.aspx'i biraz değiştireceğiz. Öncelikle C# kod sayfasını (default.aspx.cs) silelim. Sonra da default.aspx'in içini boşaltalım. Boş olunca VWD kızıp durabilir, hiç olmazsa bir HTML comment ekleyebiliriz:

Global.asax

Global kodlar yazdığımız bu sayfa hâlâ önem arzediyor. Projeye global.asax ekleyip içine garip şeyler yazacağız:

System.Web.Mvc yeni "namespace"imiz olarak ışıl ışıl yanıyor gördüğünüz gibi. Ondan sonra RouteTable diye bir şeye yeni "Route"lar eklediğimiz dikkatinizi çekecek. Kodun maksadı, [controller]/[action]/[id] formatında gelen URL'lerdeki bilgilerin nasıl ayrıştırılıp kullanılacağını belirlemek. Route ifadesi de, bu bilginin ayrıştırılıp HTTP isteğinin uygun Controller sınıfının Action nitelikli metoduna yönlendirilmesi işi söz konusu olduğu için kullanılmış. Bir başka deyişle URL'den metoda yönlendirme kuralları tanımlanıyor burada.

Sözdizim C# 3.0'a bulaşmayanlara yabancı gelecektir. Nesne hazırlayıcılar ve anonim tipler denen yeni özellikler kullanılmış.

URL yönlendirmelerini tanımlamakla ilgili Scott Bey'in URL Routing başlıklı makalesi doyurucu bir kaynak. Yine detaylardan kaçtık gördüğünüz gibi.

Controller

Projemize App_Code klasörü ekleyelim. Bu ASP.NET 2.0'den beri kullandığımız özel bir klasör adı. Bu klasör içerisindeki kod dosyaları dinamik olarak ilk istekle derleniyor.

App_Code altına HomeController adıyla bir C# sınıfı da ekleyelim. Henüz içine bir şey yazmadık, projenin vaziyeti şu:

HomeController, bizim ilk kontrolörümüz. Şimdi ona bezeyeceğimiz kod bakınız:

Dikkat edeceğimiz noktalar:

• Kontrolörümüz System.Web.Mvc.Controller isimli bir özel sınıftan türüyor.
• "Index" ve "About" isimli metodlarımıza yine aynı "namespace"e mensup ControllerAction niteliğini vermişiz.
• Metodlarımız RenderView diye gizemli bir metodu çağırıyor. Ancak ikisinde de parametreler değişiyor.

Bakalım neler olacak? Devam ediyoruz.

View

View kısmı için projeye "Views" ve içine "Home" klasörü eklemeliyiz. İllâ adları "Views" veya "Home" olmak zorunda değil ama MVC'miz öntanımlı olarak bu formatı kullanıyor. Kontrolör ismiyle "View"lar bu şekilde eşleşiyor. Bir sonraki sürümde bu ilişki yapısı özelleşebilecek.

"Home" klasörü içerisine iki adet aspx ekleyelim: "index.aspx" ve "about.aspx". Bu deneysel sitemizin iki "view"i olacak anlamına geliyor. Aspx'leri eklerken bu seferlik tek dosya olarak ekleyelim. Yani kodu ayrı bir C# sınıfında bulunmasın.

Proje ağacımız şöyle oldu:

Şimdi "index.aspx"in biraz kimyasını bozacağız:

Onu altı çizgili sınıftan (ViewPage) türeyen bir sayfa yaptık. Bu, index.aspx'in bir "View" olabilmesi için gerekli. Sayfamızda başka da özel bir şey yok. Her şey sıradan.

About.aspx'te de benzer bir değişiklik yapalım:

Run MVC, Run!

Şimdi gelelim heyecanlı kısma: bu sayfaları çalıştırmak. "F5"ten önce, projenin başlangıç özelliklerinden "şu sayfayı çalıştır" tercihini aktifleştirip karşısındaki değeri de boş bırakmanızı tavsiye ederim. Böylelikle proje başladığında uygulamanın kök dizininden başlayacaktır:

Bu devirde IE 6 kullanan kaldı mı diyor olabilirsiniz. Var efendim demek ki.

Kök dizinimizdeki "default.aspx"i hatırlarsanız içinde hiçbir malzeme yoktu. Nasıl oldu da bizim ta nerelerdeki "index.aspx"imiz "render" oldu? Cevap MVC'de efendim. Global.asax'a yazdığımız şu "Route"u hatırladınız mı?

RouteTable.Routes.Add(new Route
{
    Url = "Default.aspx",
    Defaults = new { controller = "Home", action = "Index", id = (string)null },
    RouteHandler = typeof(MvcRouteHandler)
});

Açık açık "default.aspx" diye gelecek bir URL'yi "Home" kontrolörümüzün "Index" metoduna gönder diyoruz.

Ya URL'i /home/index yaparak denersek:

Hemen tahmin edeceğiniz gibi bu URL alternatifinde global.asax'a yazdığımız ilk "Route" tanımı devreye girdi. Neydi o?

RouteTable.Routes.Add(new Route
{
    Url = "[controller]/[action]/[id]",
    Defaults = new { action = "Index", id = (string)null },
    RouteHandler = typeof(MvcRouteHandler)
});

/home/about URL'i de tanıdık bir netice veriyor:

Bozmak da kolay:

Ana sayfamızda bir eksik gözünüze çarpmıştır. Hakkında sayfasına bağlantı yok. Onu maksatlı olarak sona bıraktık. Klasik olarak linki şu şekilde verelibiriz:

Ama bunun yerine daha yapısal bir metod kullanalım. "ViewPage" temel sınıfı bize "HtmlHelper" türünde bir yardımcı nesne sağlıyor:

Netice:

Toparlayalım

Pazar günümüzü bu MVC deneyiyle geçirdik. Faydası ne oldu?

ASP.NET'in kasvetli havasının biraz dışına çıkıp tertemiz XHTML çıktılarına doğru yelken açacağımız bir mimariye giriş yaptık. Model-View-Controller üçlemesinden sadece Model'i kullanmadık ama sabredelim, bir gün o da olur.

Bilinmesi gereken bir şey var ki ASP.NET MVC hâlen geliştiriliyor. Eklenecek bir sürü özellik var. Bunlar tamamlandığında konforlu bir MVC ortamı olacağı kesin. Bir ASP.NET projesine başlayacak kişiler için de önlerine ikinci ve güçlü bir yol olarak dikilecek.

MVC ile.

 

int sayilar = new int[] {1,2,3,4,5,6,7,8,9,10};

foreach (int sayi in sayilar){   if(sayi % 3 == 0)      Console.WriteLine(sayi + "	");}

var sayilar = new[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};var uceBolunebilenSayilar = from sayi in sayilar		              where (sayi % 3) == 0		              select sayi;
foreach (var deger in uceBolunebilenSayilar)
   Console.WriteLine(deger);

public class Siparis{    public int SiparisId { get; set; }    public int Adet { get; set; }    public int UrunId { get; set; }    public decimal Tutar { get; set; }}

List sp = new List();sp.Add(new Siparis { SiparisId = 1, Adet = 1, Tutar = 20M, UrunId = 5 });sp.Add(new Siparis { SiparisId = 2, Adet = 5, Tutar = 45M, UrunId = 6 });sp.Add(new Siparis { SiparisId = 3, Adet = 15, Tutar = 65M, UrunId = 9 });

var netice = (from s in sp where s.SiparisId == 2 select s).First();Console.WriteLine(netice.Tutar.ToString());>

Kodcunun Altyapıyla İmtihanı

Bir üst framework yazmak / kullanmak ne denli zahmetlidir, biliyor muydunuz?

Microsoft yazmış bir framework, üstüne yine yazmış Application Block'lar, Enterprise Library'ler. Sonra üçüncü taraflar (çeviri Google'dan) yazmış başka başka yazılım geliştirme altyapıları. Ortalık standartlaşma, merkezileşme, kurallılaşma hevesiyle dalga dalga, duman duman.

İşveren veya "ekipler âmiri" ne istiyor? Kodcuma bağımlı olmayayım. Plug-and-play kodcularım olsun. Tuğlaları birleştiren, duvarı ören işçiler gibi. Tuğlanın yapısı hakkında, duvarın tasarımı hakkında bir fikri olmasın. Fikri olsa bile bunu kendine saklasın. İşyerinden tuğla kaçırsa bile, başka bir duvara uymadığı için tuğlalar elinde patlasın. Bir gün stok tarafında tuğla dizmiş kodcumuz, ertesi gün izne ayrılmış diğer arkadaşının yerine muhasebe tuğlaları dizebilsin. Üstelik, esneklik ister âmiri. Yazılımlar rahat rahat sünebilmelidir, genişleyebilmelidir. Her gün değişen iş ve rekabet koşullarına göre dinamik bir biçimde geliştirilebilmelidir. Kodlar yapış yapış olmuş makarnaya dönmeden konforlu biçimde yazılabilmelidir. Zaman da kazanmak ister âmir. Sıkıştırma algoritması bir kere yazılsın ister, her kodcu, gerektiğinde kendi zip'ini yazmaya kalkışıp geceler, gündüzler tüketmesin ister.

Hangi sebeple olsun altyapı gereklidir. Kodcu istesin veya istemesin, gereklidir.

Kodcunun hayalleri, idealleri vardır. Kendi algoritmalarını yazıp, kendi imzalarını atmak ister. Kod içerisine şakalı açıklamalar yazmak düşler. Kimisi âşıktır, şiire verir kendini. Döngü içerisinde sıcak kalp atışları duyulur. İtiraf.com'dan çok daha öte bir şeydir bu. Çok insancıldır. İnsan emeğinin yazılıma dönüştüğü noktada, alınteri ışıltısıdır bunlar. Kodcu, altyapının kendini sınırladığını düşünür bu zamanlarda. Altyapı olmasa süper bir kodcu olacaktır, sağdan soldan teklif gelecektir. Bu bir ressamın, yaptığı bir tablonun altına adını yazamaması gibi azap verici hâle gelir onda. Ah şu altyapı olmasa veritabanına nasıl da bağlanırım der. Nasıl da hızlı çalışan kodlar yazarım! Tüm değişkenleri tek satırda nasıl da tanımlarım. Rem'lerle adımı nasıl da yazarım kodların arasına. Ustalığımı konuştururum. Ben gitsem bile adım kalır bâki.

Öyle olmaz işte. Altyapı, kodcuyu kendi mahallesine çeker, döver de döver. Hem ruhen hem bedenen bir eğitime tâbi tutar. Kazançlı da çıkar aslında kodcu bir anlamda. Daha tertipli kod yazmayı öğrenir. Bot gibi çalışmaya başlar. Akşam eve gidince normal insana dönmesi gerekir yalnız. Altyapının da kararında olması lazımdır.

Şöyle erer ruhlar itminâna:
Devir tüketim devridir. Acımasızca bir tüketim. Bandwith'ler, "storage"lar... servet gibi yığılır insanın önüne. Tek tasarruf etmesi gereken şey "zaman"dır bu çağda. Çünkü artırdığı zamanı, daha fazla tüketim için kullanacaktır. Evet kardeşim evet, altyapı da, framework de bir tüketim aracıdır. Eskisinden daha fazla kod çalışıyorken arka planda, kodcunun daha az kod yazması, onun hakikaten daha az kod yazdığı anlamına gelmemektedir. Çünkü artan zamanda yine kod yazan kodcumuz, tüketimin zâlim çarkına girmiş bulunmaktadır.

İşin acısı nedir bilir misiniz? Bunun farkında olarak yaşamak. Ve Orta Çağ'ı kapatıp Yeni Çağ'ı açacak kudretten mahrum olmak.

Son olarak, bu da bir dış bağlantı olsun, gönülden kopan: Why frameworks are a good thing?

Yazının özgün hâli www.tahiroglu.com sitesinde yayımlanmıştır.

Doğumuna Az Kala ASP.NET 3.5 Extensions

Scott Bey, Microsoft'un "coder" görünümlü pazarlama şefi olarak bize vizyonu işaret etti. Biz de görevimizi yerine getirelim ve hadi onun pazarlama bültenine bağlantılar vererekten coşkuyu yurt sathına yayalım.

Aferin adama. Öyle bir kamu oyu oluşturuyor ki, her yazdığı binlerce insanın yazdığına temel teşkil ediyor.

Biz de geleneği bozmuyoruz efendim. 3.5 demişken devam ediyoruz. Developer Division Manager'imizin işaretiyle kalkıyoruz, şahlanıyoruz.

Scott Bey, ASP.NET'i Visual Studio 2008 ile paketledik, verdik size ama bizde durmak yok diyor. ASP.NET'e ek olarak gelişme safhasında birkaç parça ürünümüz var. Bunlar da zat-ı âlilerinin blog sayfasından ilânıyla vücut bulacak.

Bir hafta içerisinde perdelerini aralayacaklarını söylediği genişletme paketinde neler yer alıyor dersiniz?

ASP.NET MVC !

Model-view-controller mimarisinin ASP.NET'e uygulanmış iskeleti nihayet bu paket ile evlere konuk oluyor. Web sayfası icra sürecini VB Formları paradigmasından çok farklı bir şekilde ele alan MVC deseni resmi  ASP.NET dünyasında bir ilk olacak. Mevcut web sayfası icra şeklinden bunalan geliştiriciler, heyecandan kasılmış biçimde bu eklentiyi bekliyorlar. MVC'nin uygulanmasıyla arayüz katmanı iş ve tanım katmanından tamamen sıyrılacak ve bağımsız hareket edebilecek. Web formları yerine başka görünüm bileşenleri kullanılabilecek.

AJAX'ta İlerlemeler

MS artık AJAX gazını içselleştirdiği için her güncellemede bir öpücük de buraya gelecektir. Şaşırmıyoruz. Bir ilerleme örneği olarak tarayıcılardaki ileri-geri düğmeleriyle entegrasyonu haber veriyor. Daha nefis olacakmış.

Dinamik Veri Desteği ya da Scaffolding

Garip bir ad bu kabul. Türkçe'ye kimin nasıl çevireceğini bilemiyorum. Anlamamız gereken şey, bu teknik ile kod yazmadan veritabanı üzerindeki CRUD işlemlerinin kolayca halledilebildiği. Ruby on Rails dünyasında popüler olan Scaffolding, ASP.NET MVC ile MS dünyasına da giriş yapıyor. Detayları paket yayımlanınca göreceğiz.

SilverLight Batı'dan Yükselir

Biz neden kendi Flash'ımızı yapmıyoruz diye sorar birisi. Sonra olaylar gelişir. ASP.NET ile konuşma becerisi artacakmış diyorlar.

ADO.NET Entity Framework

Veritabanındaki şemanızı iş nesnelerine dönüştürmek için kullanabileceğiniz araç. LINQ ile hoplaya zıplaya çalışacağını tahmin edersiniz. Typed DataSet saçmalığının ders alınmışı. Bu framework, sanırım ASP.NET eklentisi içinde değil de ayrıca çıkacak. Fakat tarihleri yakın veya aynı olabilir.

Bitirirken...

2008'de konuşacağımız çok şey var. Geliştiriciler açısından bereketli bir yıl olacak. Windows Communication Foundation (WCF) mimari tarafta gündemimizi işgal ederken Windows Presentation Foundation ( WPF) arayüz tarafında derinleşecek. ASP.NET dairesinde MVC atılımı olacak, AJAX maydonozlaşacak. Sunucu tarafında IIS 7.0 başımıza yeni işler çıkaracak. Tarayıcı pazarında IE 8 kendine yer açacak ve SilverLight'a muhtemelen pozitif ayrımcılık yapacak. SilverLight, Flash ile mindere inecek. LINQ yeni bir uzmanlık ve danışmanlık branşı olarak parlayacak. Vista var bir de değil mi? Bir de Windows Server 2008 ve Windows Activation Services (WAS)!

Microsoft yeni yılın gündemini önümüze sermiş durumda. Yazılım dünyasında olan ve taze kalmak isteyen vatandaşlar için de yoğun geçecek demektir 2008. Cümlesine kolay gelsin.

Redirect, Transfer, RewritePath: Kahraman Olan Hangisi?

Web oldum olası, "yönlendirme" diye bir şeye ihtiyaç duymuştur. İstemci-sunucu ilişkisinin derinliklerinden, sunucu tarafındaki işlem sürecine kadar her noktada makine dilindeki JUMP komutuna benzer şekilde bir sıçrama, işlem akışını başka bir mecraya yönlendirme gerekmiştir.

ASP.NET perspektifinden olaya bakarsak, o anda çalıştırılmakta olan bir sayfadan başka bir sayfaya/kaynağa yönlenmek demektir. Ve bu dünyada yönlenmenin üç türü var: Redirect, Transfer ve RewritePath. Her biri mimarinin değişik noktalarına dokunuyor. Farklı etkilere sahip. Dilerseniz ey okur, sırayla bunları inceleyelim ve tefekkür edelim.

Redirect... Response Redirect.

ASP'nin HTTP başlıklarından "Object Moved" olanını yansıtmaya yarayan metodu. ASP.NET'e de aynı isimle devroldu. Yönlenmek istediğiniz kaynağın adresini veriyorsunuz, ASP.NET sizin için istemciye (internet tarayıcısına) "bu nesne şu adrese taşındı" başlığı gönderiyor. Tarayıcı da size hissettirmeden bu mesajı alıp o adrese ulaşmaya çalışıyor.

Dikkat ederseniz bu tip yönlendirme işleminde istemci-sunucu arasında en azından iki gelip gitme mevcut. ASP.NET'e özgü olmayan, her web programlama ortamında uygulanabilecek HTTP başlığı ile yönlendirme, böyle bir gidip-gelme dezavantajı taşıyor.

Bu metodun istemci tarafına uzanmasından ötürü, istemci gittiği hedef adresi tabî olarak biliyor. Ve bu bir internet tarayıcısı ise, kullanıcıya da o adres gözüküyor.

HTTP başlığı ile yönlendirmeler için, fazladan git-gel dezavantajına rağmen kullanım alanı yoktur denemez. Dış adreslere doğru kullanıldığında anlamlı olmaktadır. Zaten dış adreslere yönlenmeyi sadece bu metod ile yapabilmektesiniz. Birazdan detaylarını anlatacağımız diğer metodların dış adreslere yönlendirme becerisi bulunmamaktadır.

Bir diğer kullanım amacı ise kalıcı yönlendirmeler yapmaktır. Kalıcı yönlendirmeler, Response.Redirect'ten farklı bir biçimde yapılsa da temeli aynıdır. Kalıcı yönlendirme, (Permanent Redirect) 301 durum koduyla istemciye yanıt döner. Bu tip yönlendirmeler özellikle adresi kesin olarak değişmiş içerik için kullanılmaktadır. İnsanlardan daha çok web robotlarına hitap etmektedir. Onlar bu kalıcı yönlendirme mesajını kaale alarak, bir dahasına yeni adrese gitmeleri gerektiğini öğrenirler. Meselâ sitenizin yazılım altyapısını diyelim. Eski URL'ler artık geçerli değilse, bu URL'leri indekslemiş uygulamalar 404 (Not Found) alıp duracaklardır. Eski müşteriyi kaybetmemek ve verilmiş emeği hiç etmemek için eski URL'lere baştan sona kalıcı yönlendirme çekmeniz pek akıllıca bir davranış olacaktır.

Transfer

Transfer halk arasında Server.Transfer olarak da bilinir. Yine ASP'den ASP.NET'e devrolmuş bir imkandır. Adı o kadar anlamlıdır ki, yaptığı işi tam olarak ifade eder: sunucuda transfer. Bu metodda transfer işlemini yapan sunucudur. İstemci tarafıyla ilgimiz kalmamıştır. Muhatabımız sayfamızı işleten sunucu. Ve biz ona "benden pes! şu sayfayı işlet" deriz. Sunucu yeni istediğimiz sayfa için yapacağı işleri bismillah çeker ve baştan alır.

Bu metodun en güzel tarafı, istemciye bir detayın yansımamasıdır. Ama sunucuyla ASP.NET çalışma dairesi arasında yeni bir git-gel'e vesile olduğu da unutulmamalıdır. Genelde iç taraftaki dizin ve sayfa yapısını kullanıcıya çaktırmadan çalışan siteler Server.Transfer'i tercih eder. Bu metodun kardeşi olan Server.Execute ise az farklı bir şekilde işler. İstenilen sayfayı işletir ve temel sayfaya geri döner. Çok daha uzun işlenebilecek bir konudur bu Server.Transfer. Bakarız efendim bir ara.

Transfer'in bir takım handikapları yok değildir. Meselâ transfer edebileceğiniz adres bir iç ASP.NET sayfasıdır. Aslında ASP devrinde bu ikinci sayfaya değer geçirme de başlı başlına sorundu ama ASP.NET'te "query string"ler çalışıyor, sağolsun MS. İkinci sayfada Request nesnesi her şeye rağmen, size ilk adresi verecektir.

RewritePath

Son dönemin tekniğidir. ASP.NET'in HttpContext nesnesi tarafından sunulur. Kol kırılır, yen içinde kalır misâli ASP.NET çalışma dairesinin içinde gerçekleşen bir yönlenmedir. Request nesnesindeki adresi ezer ve onu ikinci sayfanın bilgileriyle doldurur. Zaten bu işlemin adı da URL'yi yeniden yazmak. ASP.NET icra dairesi bu yeni URL'yi işlemeye başlar. Sunucu isteği ASP.NET icra dairesine teslim etmiş ve cevap bekliyordur. ASP.NET de yeni sayfayı işledikten sonra sonucu sunucuya aktarır. Sunucudan da kablolar üzerinden dağlar, taşlar ve ovalar geçerek istemciye ulaşır.

ASP.NET içerisindeki istemciye yansıtılmayacak yönlendirmeler için en uygun, en hızlı metod budur. İlk URL'ye ulaşmak için HttpContext'in Items koleksiyonunu sepet olarak kullanabilirsiniz. PostBack'lerle ilgili sıkıntı yaşanacaktır kuvvetli ihtimal. Bunun çözümü de daha detaylı bir makalenin konusu. Burada yakasını bırakıverelim isterseniz.

Son Söz

Yönlendirme tiplerinin arka planını bilmek bize bilinçli yönlendirme yapmayı temin eder. Karambole yönlendirmeler, uygulama performansını olumsuz etkileyebilir.

Bu yazıda maksatlı olarak kod örneği vermedik. Okuyucunun aradığı da çok kolay bulunabilecek kod örneklerinden ziyade, meselenin iç yüzüdür. Yani kodun arkasındaki iddiadır.

İddia ile.