asp.net in yapısı ve diğer cgi tabanlı işlere göre üstünlüğünü hep abartmışımdır biraz. Fanatiklik mi diyelim artık buna, yoksa "kuzguna yavrusu şahin görünür" diye mi açıklamalı? Yazdığım kodları gözden geçirdiğimde, gerek benim .net framework ün istediği standartlara tam uyamadığım için, gerekse aslında en ideal mimari yapı asp.net yorumlayıcısı tarafından render edilemediği ama işlerin bir şekilde yürümesi gerektiği ve kodların araya sıkıştırılması sonucu, tam modüler bir yapıya halen kavuşamamışım. Ve sağda solda reklamı çıkan Dundas Upload, netadvantage chart gibi bileşenleri yazmak için takip edilmesi gereken süreç, tıpkı eski perl scriptlerini yazmak için gereken süreç gibi geliyor bana. Bu yüzden bu çelişkiye yeninin içindeki bu eskiye şaşırmaktayım daha geniş bir bakış açısından baktığımda.
Javascript kodlarının kontroller içine gömülmesi : Tasarım zamanında müdahale edilemeyen Repeater, DataList, DataGrid ve GridView gibi bileşenlerin her satırına veya her öğesine ItemDataBound veya RowDataBound olayı ile erişip, onların özelliklerine js eklemek, örneğin memnun olmadığım şeylerin başında geliyor. asp.net 3.5 örneklerinde yazılan js örneklerinde (sender,eventargs) şeklinde bir göndermeye rastladım. Acaba, biz kontrolün render edilme şeklini tahmin ederek, onların içine gerekli olayları sonradan iliştirip, js ile aspx kodlarını birbirinden iyice ayırabilir miyiz? Yapı itibarıyla her cihaza farklı render çıktısı verdiğinden (en azından teorik olarak böyle) bu hareketten çekinmekteyim.
Javascript kodlarının <body> düğümü içine yazılması : Master Pages çıktı çıkalı bu tür hatalı örneklere rastlamaktayım. Ancak bunun çözümü basit. <head> içinde ayrı bir ContentPlaceHolder tanımlayıp, onun içinde CSS ve js kodlarımızı yerleştirebiliriz.
CSS veya Temalar : App_Themes ile birlikte nesneye iliştireceğimiz CSS class(ları) ve özellikleri kodun içinden ayıklanmış durumda. Bu durumdan çok memnunum. Ancak nesnenin ClientID değerini <%%> bloğu olmadan elde etmenin bir yolu olmalıydı diye düşünüyorum.
Platform anlayışı, (dil & kütüphane ayrımı) : Python un sloganı olan "batteries included" anlayışının bir benzeri bizde de var. Madem asp.net kullanıyorsun, o halde senin kullanacağın kütüphane bellidir? Common Type System nedeniyle aynı tipleri paylaşan tonla (ama pratikte iki adet C#, VB) dil var. Bu çok kullanışlı bir şey olsada gittikçe kullanılan kütüphanelerin her yeni sürümle birlikte kullandığımız platforma eklenmesinin bazı sakıncaları olduğunu düşünüyorum. Nedir bunlar?
- "Platformumuzun" boyutu şiştikçe şişiyor.
- Platformumuzu başka işletim sistemlerine taşımak (port) isteyenlerin işi artıyor, zorlaşıyor.
- İdeal mimariden (sapla samanı, markup ile js i css i ayırmamak mesela) uzaklaşma tehlikesi doğuyor.
.net framework 1.0 dan bu yana, şu ünlü /bin klasörüne atılan assembly lerin otomatik olarak entry point inin bulunduğu ve üçüncü parti kütüphanelerin çalışmaya hazır hale gelmesi gibi büyük bir nimet var elimizde buna karşılık. Ancak bu doğal koda (native code) çağrı yapmayan kütüphaneler (mscorlib.dll harici dll ler) için geçerli.
Eğer biz, asp.net kullanıyor ve onunla kodluyor isek, (bence) kodlama konusunda bir takım prensipler belirlememiz gerekli. Öncelikle kullandığımız platforma, platform gözüyle bakmamız gerektiğine inanıyorum. Pazarlama amaçlı "her yerde çalışabilir" sloganlarını ancak biz gerçekten işler hale getirebiliriz, tabii eğer tercihimiz bu ise veya ileride bunu düşünüyorsak şimdiden bazı alışkanlıklarımızı değiştirmemiz faydalı olacaktır.
Haftaya yazmayı planladığım bir sonraki yazıda:
- Mono bizim için ne kadar kullanışlı olabilir?
- Silverlight hakkındaki görüşler (Burada Azer Koçulu nun bir sunumundan da faydalanacağım)
- Ajax kütüphaneleri ve dhtml frameworks, nasıl entegre edebiliriz?