evcil.net noktanın egemenliği

IIS 7 ile Fazlalıkları Aldırabiliyoruz

Son zamanlarda parlayan bir iş kolu var: SEO uzmanlığı ve danışmanlığı. SEO arama motoru optimizasyonu manasına gelip teknik bir kavram görüntüsü verse de esas olarak sanal ortamın arama motoru odaklı pazarlama faaliyetlerine işaret ediyor. Arama motorları - özellikle Google - devlerin ve cücelerin güreş meydanına dönmüş durumda.

Size bu olimpik atmosferde koçluk tavsiye edenler de çok olacaktır. Kapınızı SEO SEO diye çok aşındıranlar bulacaksınız. Web ile ilgili bir şeylere gözünüz takıldığında SEO-Friendly denen şeyin ne de çok tekrar ettiğine şahit olacaksınız.

Bu tavsiye dizilerinde en çok geçen başlıklardan birisi, temiz ve manalı URL meselesidir. Eskiden karışık kuruşuk, şifrelenmiş URL'ler prestij meselesi iken SEO ilkeleri durumu tersine çevirmiştir. Yâni Hotmail'in hâlâ devam ettirdiği şu URL yapısına mukabil:

http://login.live.com/login.srf?wa=wsignin1.0&rpsnv=10&ct=1199394131&rver=4.5.2130.0&wp=MBI&wreply=http:%2F%2Fmail.live.com%2Fdefault.aspx&id=64855

şunun gibi URL'ler:

https://secure.del.icio.us/login

daha evlâ denilmektedir.

Haklıdır diyen. Çünkü arama motorları, web sayfaların içeriklerini değerlendirdiği kadar onu tarif eden bilgilerin de aydınlatıcı olmasına dikkat ediyor. Ve kaynağın adresini (URL) içeriği tarif eden bir parametre olarak ele alıyorlar.

Bu vaziyet, web mimarlarını ürettikleri sayfaların URL'lerine de dikkat etmeye zorluyor. Ne yapıyorlar? URL'deki tüm fazlalıkları atmaya ve URL'i sadece sayfayı anlaşılır biçimde tarif eden ifadelerle sınırlandırmaya çalışıyorlar. Böylece meselâ, "Yine Bir Gülnihâl" başlıklı bir yazının bulunduğu sayfaya URL'i ile ulaşabiliyoruz. Veya arşivin belirli bir tarihe ait kısmına http://siteadresi.com/arsiv/2007/05/01 diyerek ulaşabiliyoruz. Arınmış URL kullanan sitelere örnek olarak www.dobisko.com'u gösterebiliriz. Dobişko'da tüm mekan adları, iller, semtler URL'den anlaşılabilir şekilde adreslenmiş. Siteyi gezerken adres çubuğu adeta dile geliyor, konuşuyor: http://www.dobisko.com/eniyi10/balikci.

Konuşkan URL'ler Nasıl Yapılır?

Konuşkan URL'lerdeki en önemli iş, dosya uzantılarını kaldırmak. "Logon.php" veya "logon.asp" gibi dosya adlarından sondaki php ve asp'yi silmekten bahsediyoruz.

Apache sunucularda bu çok rahat yapılabiliyor. O nedenle PHP-Apache ikilisini kullanan yazılımlar genelde bunu uyguluyor.

Ya Microsoft'un IIS yazılımına mahkum olanlar ne yapsın? Yok mu ellerinden tutan, yok mu bir yol gösteren?

IIS 6 ve Öncesi İçin Çözümler

Uzantısız adresler kullanmak için iki yöntem var. Birisi paylaşımlı "hosting" ortamlarında da uygulanabilen 404 yakalama metodu; diğeri de "wildcard mapping" denen uygulama alanı dar ama nispeten daha yapısal olan bir çözüm.

404 Avı

Hep moral bozacak değil ya şu 404 "Sayfa Bulunamadı" hatası. İşte doğru kullanıldığı yerde kurtarıcı bile olabiliyor. Paylaşımlı "hosting" ortamlarında neyse ki kontrol panelleri hata dokumanlarını kontrol etmeye müsade ediyor. Hata dokumanlarından 404'ü kendi özel adresiyle değiştiren web mimarını çok güzel şeyler bekliyor! Çünkü IIS, bulunamayan sayfa için hata adresini çağırıyor ama peşine de istenen sayfanın adresini parametre olarak ekliyor. Dileyen kişi, bu hata sayfasında istediği kod kümesini çalıştırıp kullanıcıyı beklediği sayfaya yönlendirebilir. Az evvel örnek verdiğimiz Dobişko, ASP-IIS kullanmasından mütevellit, konuşkan URL standardına böyle ulaşıyor. Basit, iş gören ama "amele" kategorisinde bir çözüm.

Wildcard Mapping; Vahşi ama Yapısal

Basit. ISAPI filtrelerine bir yenisini ekleyip gelen her isteği (wildcard'dan kasıt bu: *) ASP.NET ISAPI bekçisine vermek demek. Her istekte sizin gerekli denetimleri yapıp "URL Rewrite" mi yapacaksınız artık ne yapacaksanız, yapın demek oluyor. ISAPI filtresi çözümü, web sunucu elinizde ise gayet hoş bir çözüm. Hatta bu işi daha detaylı yapan özel üçüncü taraf ISAPI filtreleri de var, satılıyor. Çözüm çok ama sunucu sizin elinizdeyse. Eğer bir "hosting" firmasının sıradan bir müşterisiyseniz bu iş için 404 avına talim edeceksiniz demektir.

Ya da durun, IIS 7'den bir şeyler diyelim size.

IIS 7'den Sonrası

IIS 7'de beklenen bir şey gerçekleşti ve ASP.NET, IIS ile kaynaştı. Ön tanımlı olarak kaynaşmış kipte çalışıyorlar. Bu kaynaşmanın doğal semeresini web.config fermanında bulabilirsiniz. Yapılandırma dosyamız artık adlı bir unsur içeriyor. Web sunucudaki bir çok ayarı web.config dosyasından yapabileceğiz demektir bu.

Yapabileceğimiz ayarlar içerisine "wildcard" sembolleriyle "handler" eşleme de giriyor, her istekte patır patır çalışan modülleri belirlemek de.

IIS 7'de uzantısız ASP.NET sayfaları kullanmak için en pratik yöntem HttpModule kullanmak. Yazacağınız özel bir modülü her istekte çalışacak şekilde ayarladıktan sonra kodunuz bayram edecek.

Ancak kod yazma zahmetinden biraz kurtulmak isteyenlere açık kodlu bir tavsiyemiz var: UrlRewriter. Gayet efendi, işini düzgün yapan bir uygulama. Avantajı şu ki sadece web.config dosyasına yazacağınız laflarla URL gölgeleme işlerini hallediyorsunuz. Uygulama kodunuza eklemeler yapmanıza hiç lüzum yok.

Hâsılı...

IIS 7, Vista ve Windows 2008'in parçası. ASP.NET ile bütünleşmesi gayet güzel. Konuşkan URL'ler yapmak da epey kolaylaştı. Deneyin.

SEO ile.

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.

 

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.

İlk ASP.NET MVC Kod Örnekleri

Haftalardır ASP.NET'in MVC atağını konuşup duruyoruz. Henüz millet olarak kodlayıp denemiş değiliz. Şimdilik bakınmakla yetiniyoruz.

Bir yandan Las Vegas'tan DevConnections 2007 esintileri vuruyor yüzümüze. üstad Metin Karabiber de, bu esintiyi "vatan borcu" hassasiyetinde ufaktan taşımış, sağolsun.

DevConnections, doğal olarak ASP.NET MVC'yi de büyük bir kitle önünde sergilemek ve ilişkiyi diri tutmak için güzel fırsat. Nitekim Microsoft ekibi fırsatı değerlendirmiş ve bir sunum yapmış. Hanselman ve Elion arkadaşların sunumunu inceleminizi salık veririm.

Sunumdan çıkan ufak notları da buraya nakşedelim. [Parantez içi sözler fakire ait]

- ASP.NET MVC, hayatımıza test-yönelimli geliştirmeyi, gevşek bağlı bileşenleri getireceğine dair söz veriyor.
- URL'ler artık /UrunDetay.aspx?UrunId=26&ShowBasket=true şeklinde saçmalamaktan kurtuluyor, REST ve SEO ile samimi hâle geliyor: /urundetay/kahve-makinesi/showbasket vs. [Aman efendim, en çok sevindiğim şeylerden birisi.]
- üstüne basa basa denen o ki, Web Form'lar bitmiyor. Web Form yerli yerinde dururken, MVC ona alternatif olarak ikram ediliyor. Artık Web Form zorlanan bir şey değil, tercihlerden sadece biri oluyor. [Ha şöyle.]
- Artık gevşeyin diyorlar. Dependency Injection (DI) veya Inversion of Control (IOC) teknikleriyle genişleyebilen uygulamalar yazın, coşun diyorlar.
- MVC altyapısı, ASP.NET'in sınıf hiyerarşisindeki karşılığı olan System.Web'den veriliyor.
- Tüm "açık kaynak" dünyasıyla da barışık deniyor. Meselâ "model" katmanında NHibernate, "view" katmanında Brail kullanabileceğimiz söyleniyor.

Bir "kontrol" sınıfından kod örneği:

[ControllerAction]
public void ShowPost(int id) {
     Post p = PostRepository.GetPostById(id);
     if (p != null) {
         RenderView("showpost", p);
     } else {
         RenderView("nosuchpost", id);
     }
}

Rahatlıkla anlaşılacağı gibi bu metod bir URL'yi temsil ediyor.

URL'ler kontrolörlere yönlendiriliyor. Onlar da bir iş yapıp akışı bir "View"a havale ediyorlar. "Rendering" için klasik Web Form bileşenleri kullanmanın yanında NVelocity, Brail gibi başka motorlar da kullanabiliyoruz. [Evet, gevşek bağlılık sayesinde.]

...

Cümle MVC taraftarı, web'in doğasına aykırı buldukları Web Form'larına nicedir veryansın ediyordu. Şimdi de bu Microsoft implementasyonuna biraz mesafeli duruyorlar. Bakalım perdeler açılıp CTP vitrine konunca kodlayan parmaklar ne diyecek?

Önyargısız takip ediyoruz ey okur.

ASP.NET MVC Framework ve Düşündürdükleri

Perde aralandı. Son günlerin çok konuşulan mütevazi Microsoft adamı Scott, ASP.NET'e eklenti olarak geliştirdikleri Model-View-Controller altyapısından ipuçları vermeye başladı.

Bir vakitler belirtmiş idik, ASP.NET'in millete bir beden büyük geldiğini. Çünkü her şey bir "framework" olmuş ve koda uzanan ellerimiz itilmişti. ViewState'in mucize olduğuna inandık bir süre. Page LifeCycle'ı tabiattaki Azot döngüsü kadar önemsedik.

Ne oldu? Her seferinde gelip bir duvara tosladık. Kımıl kımıl, kolayca test edilebilir, ayrıştırılabilir, basit ama güçlü web uygulamaları yazamaz olduk.

Alternatif teknoloji takipçileri, koşmaya başladı; biz yorulduk, nefesten kesildik. O millet, Ruby ile harman kaldırırken biz "Eti'nin bisküvisi mi? Hmm tadı güzel, askerde çok yedim." demekle meşguldük.

Birileri de bu işten fena sıkıldı bizim gibi. Şu MonoRail işte benzer kabızlığın mahsülü.

Nihayet Microsoft da Scott'un ağzından "Pes!" dedi. Geliyor. Sizi özgürleştirecek açılımımız geliyor.

Model-View-Controller yaklaşımı kurtarıcı mı? Kahraman mı? Asla. Ama ASP.NET'in resmî çalışma şekli açısından ciddi bir yenilik. Bağıra bağıra sunulan o "State Management" özelliğinin bir kenara bırakılıp yeni bir sayfa işleme sürecinin yeni bir anlayışla ele alınması demek.

Önünüz açık artık ASP.NET'çiler. Web Formlarının varsayılan mekanizmasının dışına çıkma vaktiniz gelmişti!

ASP.NET’in Geleceği

Bir yerlerde ALT.NET konferansı düzenlendi. Guru'lar ASP.NET'in geleceğini
konuştu.  

Ve yumurta: Microsoft, resmi ASP.NET'in demode olması ve işlevsizleşmesi tehlikesini gördü ve MVC
(Model View Controller) yolundaki adımını attığını söyledi. 

Yukarıdaki görüntü konferanstan. ALT.NET'ten. 
MVC sene sonuna seçkin
marketlerde.