ASP.net MVC Framework'e giris

Print Versiyonu

Microsoft ASP.net MVC Framework'e Giris

MVC, 80li yillarin sonundan itibaren varolan bir tasarim kalibi. Asil amaci sunum/model/business katmanlarini ayirmak olan bu pattern bir cok web frameworkunun temelini olusturuyor.
M harfi, Modeli yani bir diger deyisle verimizi temsil ediyor. V harfi View'i diger bir deyisle sunum katmani/goruntuleri temsil ediyor, C harfi ise View'i secen, gerekli veriyi ona gonderen yapilari temsil ediyor.

Java'da bir cok projede ve RoR(Ruby on Rails)'de kullanilan bu yapi, Microsoft'un MVC Framework'u ile .net dunyasinda da meshur olmaya basladi. Daha once productionda kullanilabilen mukemmel Monorail vardi fakat microsoft markasi olmadigi icin belirli bir kesimle sinirli kaldi. Monorail'i inceledigimizde isimlendirmeden ozelliklere Monorail'in Microsoft'a ilham kaynagi oldugunu soyleyebiliriz.

Bu kisa giristen sonra webforms'un sorunlarindan ve MVC framework ile farklarindan bahsedelim.

1. Webforms windows formsun durumlu(?)(stateful) yapisina web uygulamalarini yaklastirmak amaciyla yapildi ve bu yuzden bir cok soyutlamaya gidildi.
   ViewState, PostBack gibi durum bilgileri ve cesitli olaylar bunun bir parcasi. Bunlarla ilgilenmek, hanginin ne zaman tetiklenecegini, ne zaman sisecegini tahmin etmek oldukca guc.
2. Durum bilgileri ve cesitli olaylar sirasinda bir cok islemin yapilmasi(viewstate in requestten alinip control'un durumunun ona gore belirlenmesi gibi) nedenlerle performans konusunda oldukca yavas.
3. Control'lerin yeterince ozellestirilebilir olmamasi ve olusturdugu yonetilmesi zor kodlar sayfa icin buyuk bir tehlike. En azindan kontrol'lere verilen id'leri dusunmek bile bir fikir verebilir.
4. Webforms web uygulamalarinin gercek yapisini cesitli olaylarla gizler ve bu da test edilebilirlik icin fazlaca karmasiklik teskil ediyor.
5. Olaylarin farkli siralarda calismasi ve kontrol statelerinin gercekte tutulmamasi fakat viewstate'den getirilmesi yine test edilebilirlik icin bir engel.

Webforms'a kotu demek istemiyorum, sonucta bu kisisel tercih meselesi. Webforms kesinlikle kotu degil, bircok senaryoda bizim icin yeterli fakat kotu ozellikleri de bas agrisi yapiyor.

MVC framework Monorail'den esinlenilerek yapilmis bir framework. Monorail'de gordugum bir cok sey ASP.net MVC Framework'te de karsima cikti. Bu durumda ikisi hakkinda genel tecrubelerimi aktarsam bir digeri icin pek de yanlis olmaz sanirim. ASP.net MVC frameworkun en buyuk avantaji yillardir suregelen ve bu yuzden kanitlanmis bir kaliplari/mimarileri bunyesinde barindirmasi. Bu yuzden yazdiginiz kod "genellikle" eskiden yazdiginizdan daha kaliteli olacak cunku bazi katmanlari zorunlu olarak birbirinden ayirmis olacaksiniz(seperation of concept). Tabi bu sizin yine de kotu kod yazmaniza engel degil.

Genel olarak MVC framework'u 3 konsepte bolebiliriz

Front Controller

FrontController Requesti isleyip yapilan cagrinin nereye yonlendirilecegini belirleyen yapi. MVC framework icin bu basitce girilen url'nin hangi controller'a ve onun hangi action'una yonlendirilecegine karar veren Routing mekanizmasi ve HttpHandler. Avantaji bizi kullanici-dostu url'lerden SEO'lardan buyuk olcude kurtarmasi.

Controller

MVC kisaltmasindaki C harfinin acilimi. Bir Controller her biri ozel bir istegi karsilamakla gorevlendirilmis cesitli Action'lardan olusur. Bir action cesitli business classlariyla veya modelle etkilesip herhangi bir View(goruntu)'yu ekrana gonderebilecegi gibi baska bir action'a yonlendirmeyi de secebilir. Bu tur kararlar herhangi bir View ekrana gonderilmeden once verilir ki bu Webforms'da yapamayacagimiz bir seydir. Webforms genel olarak kendi kendini render etmekle ilgilidir aslinda yaptigi her sey de bunun icindir. MVC framework bu yuzden Webformsdan kesin bir sekilde ayrilir ve su yonlerde fayda saglar:

1. Web context'i disinda test edilebilirligi
2. Kolay debug edilebilir olmasi ve bu yuzden yonetiminin kolay olmasi
3. Sizi katmanlara bolmeyi zorlayarak daha iyi bir mimariye gitmeniz
4. Cesitli programlama tekniklerine daha genis imkan vermesi(inversion of control, dependency injection, aspect oriented programming, vs)
5. Webforms'a gore daha kolay programlanabilirlik
6. Test edilebilirlik, test edilebilirlik ve test edilebilirlik.

View

View bizim bir sayfaya istek yaptigimizda bize donen sonuc. MVC framework ve Monorail Template tabanli bir yapi kullaniyorlar, yani daha once kullandiginiz bir template engine varsa onu MVC icin kullanilabilir hale getirmek sizin icin hic de zor olmayacaktir(bunun ornegini ilerleyen makalelerde yapacagiz). Bu template kullanan yapisi MVC frameworkunun hafif ve ayrik bir gorunum sistemine sahip olmasini sagliyor. Bu View yapisi ayrica gelen header'a gore uygun formatta sonuc gosterebilmenize de yariyor. Ornegin kullanici browserla istek yaptiginda HTML gosterirken JSON istegi oldugunda JSON ve XML seklinde istediginde XML gosterebilirsiniz hem de farkli bir controller kullanmadan, tamamen ayni kodla(reusability)

Sonuc:
ASP.NET MVC Framework su an CTP asamasinda ve mukemmel olmaktan cok uzak. Bir cok eksigi var (CTP olmasi yuzunden eksiklerinin olmamasi beklenemez), ornegin Filter(action calismadan once ve sonra yapilan islemler-action'a sadece adminin girmesini saglamak gibi) veya kendi yonetimli View Componentlerinin olmamasi(bu kelime monorailden kalma, bunun microsoft karsiligi subcontroller+usercontrol), Webforms viewengine'in henuz tam oturmamis olmasi, hata kontrollerinin explicit olarak yapiliyor olmasi, parametre baglayicilarinin olmamasi ve bazi tasarim kararlari(Actionlarin tepesine [ControllerAction] koyma zorunlulugu gibi) gosterilebilir. Fakat microsoft'un bir degisiklik ypaip OpenSource bir projeden esinlenmesi ve onun tecrubesinden yararlanmasi gelistiriciler icin iyi bir karar.