[]
MVC bu mu oluyor?
cehaletimi mazur görün.
web yazılımla uğraşıyorum bir süredir. son 8 aydır da front end dışında pek işe el atamadım açıkçası. geliştirmek istiyordum ama işyerindeki yoğunluk nedeniyle ekstra işlerle hiç uğraşamadım.
mvc hakkında pek bilgim yok o yüzden. ama bir şey oldu;
ben sitelerin backendleriyle de uğraşıyorum ve onları kodlarken sürekli farklı teknik kullanmaya çalışyıorum her seferinde daha pratik yapmak için. yani hiçbir zaman iki siteyi aynı şekilde kodlamadım diyebilirim, daha iyisini bulmaya çalışıyorum.
otobüs yolculuklarım uzun geçtiği için de elime kağıt kalem alıp kafamda bir şeyler kurguluyorum. dün akşam şöyle bir kurgu yaptım;
tüm class'larımı bir klasöre, tüm html dosyalarımı başka bir klasöre koyayım.
bir başka klasörden de bu ikisinin yönetimini yapayım yani hem classları hem template dosyalarını bir yönetim klasöründen idare edeyim. hem kontrolü hem müdahalesi kolaylaşsın.
sonra internette buna benzer modalleri öğrendim. mvc'yi duymuştum, mvc nasıl acaba dedim. ve sanırım benim dediğim sisteme benziyor.
cehaletim için tekrar kusura bakmayın ama, ben kendim mvc mimarisini mi oluşturmuş oldum? yoksa mvc biraz daha mı farklı? eğer bunu kendim ürettiysem hakikaten mutlu olucam, çünkü dorğu yönde düşünüyorum demektir. mvc buna benzer değilse de, bildiğimi yapmaya devam edicem o ayrı :)
web yazılımla uğraşıyorum bir süredir. son 8 aydır da front end dışında pek işe el atamadım açıkçası. geliştirmek istiyordum ama işyerindeki yoğunluk nedeniyle ekstra işlerle hiç uğraşamadım.
mvc hakkında pek bilgim yok o yüzden. ama bir şey oldu;
ben sitelerin backendleriyle de uğraşıyorum ve onları kodlarken sürekli farklı teknik kullanmaya çalışyıorum her seferinde daha pratik yapmak için. yani hiçbir zaman iki siteyi aynı şekilde kodlamadım diyebilirim, daha iyisini bulmaya çalışıyorum.
otobüs yolculuklarım uzun geçtiği için de elime kağıt kalem alıp kafamda bir şeyler kurguluyorum. dün akşam şöyle bir kurgu yaptım;
tüm class'larımı bir klasöre, tüm html dosyalarımı başka bir klasöre koyayım.
bir başka klasörden de bu ikisinin yönetimini yapayım yani hem classları hem template dosyalarını bir yönetim klasöründen idare edeyim. hem kontrolü hem müdahalesi kolaylaşsın.
sonra internette buna benzer modalleri öğrendim. mvc'yi duymuştum, mvc nasıl acaba dedim. ve sanırım benim dediğim sisteme benziyor.
cehaletim için tekrar kusura bakmayın ama, ben kendim mvc mimarisini mi oluşturmuş oldum? yoksa mvc biraz daha mı farklı? eğer bunu kendim ürettiysem hakikaten mutlu olucam, çünkü dorğu yönde düşünüyorum demektir. mvc buna benzer değilse de, bildiğimi yapmaya devam edicem o ayrı :)
Yani mvc iki klasore ayirmaktan biraz daha farkli tabii. Ama gidis yolun ayni diyebilirim.
- f_d
(20.03.15 12:20:35)
hayır. mvc o değil.
mvc'de url'ler dosyaları hedeflemez. bu nedenle dikkat ettiysen url'lerde uzantı (.aspx vb) yoktur. bunun yerine route'lar vardır. mvc'nin route mantığı, gelen url'yi daha önce tanımladığın bir route pattern'i ile eşleştirir ve bu route'dan hangi controller ve bu controller'un hangi method'unun sorumlu olduğunu belirler. gene senin tanımlamana göre. route ile parametre taşıyabilirsin, bu parametre tanımların da controller'ın ilgili method'una parametre olarak iletilir.
controller'ın görevi gelen bu isteğe göre bir model (data) kullanarak view oluşturmaktır ve isteği yanıtlamaktır. view'lar önceden tanımladığın ve model verisine ulaşabilen özel html dosyaları. bu view'ları template gibi düşünmek gerekir. mvc engine, bu view ve model'i kullanarak bir html oluşturur. view içerisinde döngüler, kontrol blokları vs kullanabilirsin.
temel iş akışı böyle. normal bir web uygulamasında yapılamayan ama mvc'de yapılabilen bir şey yok, tersi de doğru. bu bir seçim.
en temel avantajları
+ seo friendly. okunabilir url oluşturuyorsun
+ client side code üzerinde kontrol sende oluyor.
+ uygulama katmanlarını (ui, business logic, database vs) ayırmak daha kolay. ekip geliştirme için daha uygun.
mvc bir pattern, dile has bir konu da değil. asp.net, php, node.js, java vb. her dil için bir mvc framework mevcut.
mvc'de url'ler dosyaları hedeflemez. bu nedenle dikkat ettiysen url'lerde uzantı (.aspx vb) yoktur. bunun yerine route'lar vardır. mvc'nin route mantığı, gelen url'yi daha önce tanımladığın bir route pattern'i ile eşleştirir ve bu route'dan hangi controller ve bu controller'un hangi method'unun sorumlu olduğunu belirler. gene senin tanımlamana göre. route ile parametre taşıyabilirsin, bu parametre tanımların da controller'ın ilgili method'una parametre olarak iletilir.
controller'ın görevi gelen bu isteğe göre bir model (data) kullanarak view oluşturmaktır ve isteği yanıtlamaktır. view'lar önceden tanımladığın ve model verisine ulaşabilen özel html dosyaları. bu view'ları template gibi düşünmek gerekir. mvc engine, bu view ve model'i kullanarak bir html oluşturur. view içerisinde döngüler, kontrol blokları vs kullanabilirsin.
temel iş akışı böyle. normal bir web uygulamasında yapılamayan ama mvc'de yapılabilen bir şey yok, tersi de doğru. bu bir seçim.
en temel avantajları
+ seo friendly. okunabilir url oluşturuyorsun
+ client side code üzerinde kontrol sende oluyor.
+ uygulama katmanlarını (ui, business logic, database vs) ayırmak daha kolay. ekip geliştirme için daha uygun.
mvc bir pattern, dile has bir konu da değil. asp.net, php, node.js, java vb. her dil için bir mvc framework mevcut.
- screamshot
(20.03.15 12:28:30)
MVC dosyalarla ilgili degil de kod yapisi üzerinde kurulan mimari desendir. Büyük web projelerinde en cok yasanan problem yazilan kodlarin birbirine bagimliliginin cok yüksek olmasi.
Mesela klasik bir web mimarisinda bir sayfada kullanici listesini göstereceksin. View katmaninda yani html sayfasinda php/java gibi dillerle bir döngü olusturuyorsun ve back end den bana ilk 100 kullaniciyi gönder diyorsun. sonra bunlari listeliyorsun. Bir kullaniciya tikliyorsun ve javascript (genelde controller yükünü javascript üstlenir) back-ende bir istek gönderiyor kullanici id si su ve bunun bilgilerini bana gönder diye. Tabi bu yapida cok büyük bi problem oluyor, html, javascript, ve programlama dili o kadar ici ice ki birinde degisiklik yaptiysan hepsinde yapman gerekiyor. Ayrica is mantigini da (yani döngüler, kararlar vs) html(cogu durumda html dosyasi .asp .jsp .php olabilir ama aslinda html data ve icine serpistirilmis asp/php,java kodu icerir) icine gömülen kodlarla yapiliyor ve bu da karmasik yapilarda (isin icine bir de asyncronous istekler yani ajax girdiyse) isin icinden cikilamiyor.
Buna cözüm olarak MVC sunu sunuyor bi kere View katmani tamamen bagimsiz olacak, karar ve is mantigina karar vermeyecek. Sen bi sayfai actiginda View katmani o sayfadaki temel html elementlerini yerlestirecek, kac tane kullanici listelenecek, kac sira ile listelenecek, hicbirseye karismayacak. Ikincisi ise Modal kismi yani Kullanici, kullanicinin adresi, özellikleri gibi hierarsik yapi tamamen ayri olacak. Buna sadece Modal kismi karar verecek. Modal kisminin yükünü bir programlama dili ceker ve kararlari döngüleri bu dil ile modal kisminda yaparsin. Modal bi parametre alir mesela kulalniciSayisi=100, sonra bu 100 kisiyi arar bulur, tüm yan bilgilerini (kullanicinin adresi, özellikleri vs) ekler, siralar, filtreler. Modal kisminda data dört dörtlük hazir olur. Iyi de bu modal kismina kullaniciSayisi=100 parametresini ne gönderecek? iste bunu Controller yapar. Genelde bu isten javascript sorumludur (herhangi bir framework kullaniliyorsa javascript olmayabilir, mesela ASP MVC framework gibi, ya da javada JSF gibi, onun disinda bu controller görevini javascript library de üstlenebilir angular.js gibi) Bu controller, gerek url den aldigi parametreler, gerek tiklanilan elemanlara göre http parametrelerini hazirlar Modal a gönderir, modal datayi dört dörtlük harizlar sonra controller a geri verir, controller da datayi alir View katmanina gönderir, View de bunlari gösterir. View ve Controller asla karar mekanizmasina girmez.
En büyük avantaji herkesin görevi belli oldugu icin birbirinden ayirmak, kendi icinde degisiklik yapmak kolay olur. Parametreler sabit oldugu sürece iletisimde problem olmaz. Ayrica testler kolay olur cünkü her katmanin ne alip verecegi, yükümlülükleri sabttir. Mesela kullanicilar yanlis siralandiysa bilirsin ki bundan sadece Modal sorumludur, controller yada view katmanina bakmazsin bile. Modal katmanini acarsin, debug yaparsin niye yanlis sirali bulursun cözersin. Modal da cözdünmü hersey cözüldü demektir, yaptigin degisiklik yüzünden View yada controller da degisiklik yapmak durumunda kalmazsin.
Cok soyut bir durumdur MVC dosyalarla aciklayamazsin, sadece kodun mimarisi ile ilgilidir.
Mesela klasik bir web mimarisinda bir sayfada kullanici listesini göstereceksin. View katmaninda yani html sayfasinda php/java gibi dillerle bir döngü olusturuyorsun ve back end den bana ilk 100 kullaniciyi gönder diyorsun. sonra bunlari listeliyorsun. Bir kullaniciya tikliyorsun ve javascript (genelde controller yükünü javascript üstlenir) back-ende bir istek gönderiyor kullanici id si su ve bunun bilgilerini bana gönder diye. Tabi bu yapida cok büyük bi problem oluyor, html, javascript, ve programlama dili o kadar ici ice ki birinde degisiklik yaptiysan hepsinde yapman gerekiyor. Ayrica is mantigini da (yani döngüler, kararlar vs) html(cogu durumda html dosyasi .asp .jsp .php olabilir ama aslinda html data ve icine serpistirilmis asp/php,java kodu icerir) icine gömülen kodlarla yapiliyor ve bu da karmasik yapilarda (isin icine bir de asyncronous istekler yani ajax girdiyse) isin icinden cikilamiyor.
Buna cözüm olarak MVC sunu sunuyor bi kere View katmani tamamen bagimsiz olacak, karar ve is mantigina karar vermeyecek. Sen bi sayfai actiginda View katmani o sayfadaki temel html elementlerini yerlestirecek, kac tane kullanici listelenecek, kac sira ile listelenecek, hicbirseye karismayacak. Ikincisi ise Modal kismi yani Kullanici, kullanicinin adresi, özellikleri gibi hierarsik yapi tamamen ayri olacak. Buna sadece Modal kismi karar verecek. Modal kisminin yükünü bir programlama dili ceker ve kararlari döngüleri bu dil ile modal kisminda yaparsin. Modal bi parametre alir mesela kulalniciSayisi=100, sonra bu 100 kisiyi arar bulur, tüm yan bilgilerini (kullanicinin adresi, özellikleri vs) ekler, siralar, filtreler. Modal kisminda data dört dörtlük hazir olur. Iyi de bu modal kismina kullaniciSayisi=100 parametresini ne gönderecek? iste bunu Controller yapar. Genelde bu isten javascript sorumludur (herhangi bir framework kullaniliyorsa javascript olmayabilir, mesela ASP MVC framework gibi, ya da javada JSF gibi, onun disinda bu controller görevini javascript library de üstlenebilir angular.js gibi) Bu controller, gerek url den aldigi parametreler, gerek tiklanilan elemanlara göre http parametrelerini hazirlar Modal a gönderir, modal datayi dört dörtlük harizlar sonra controller a geri verir, controller da datayi alir View katmanina gönderir, View de bunlari gösterir. View ve Controller asla karar mekanizmasina girmez.
En büyük avantaji herkesin görevi belli oldugu icin birbirinden ayirmak, kendi icinde degisiklik yapmak kolay olur. Parametreler sabit oldugu sürece iletisimde problem olmaz. Ayrica testler kolay olur cünkü her katmanin ne alip verecegi, yükümlülükleri sabttir. Mesela kullanicilar yanlis siralandiysa bilirsin ki bundan sadece Modal sorumludur, controller yada view katmanina bakmazsin bile. Modal katmanini acarsin, debug yaparsin niye yanlis sirali bulursun cözersin. Modal da cözdünmü hersey cözüldü demektir, yaptigin degisiklik yüzünden View yada controller da degisiklik yapmak durumunda kalmazsin.
Cok soyut bir durumdur MVC dosyalarla aciklayamazsin, sadece kodun mimarisi ile ilgilidir.
- emrahday (20.03.15 13:15:49 ~ 13:23:17)
@scream,
hocam zaten direkt dosyaye yönlendiren yazılımcı olmaz ki? php php site yazılmaz tabi ki senin söylediğin gibi olacak aslıdna.
hocam zaten direkt dosyaye yönlendiren yazılımcı olmaz ki? php php site yazılmaz tabi ki senin söylediğin gibi olacak aslıdna.
- tchuck (20.03.15 13:22:08 ~ 13:45:55)
@tchuck
"dosya route etmek" diye bir kavram yok zaten. anlamadım soruyu.
"dosya route etmek" diye bir kavram yok zaten. anlamadım soruyu.
- screamshot (20.03.15 13:31:57)
1
