model view controller

wondrous wondrous
mvc, yazılım mühendisliğinde popüler bir design pattern'dır. bu üçlüyü eğer sözlükte tire işareti başlıklarda otomatik olarak silinmemiş olsaydı model-view-controller olarak görecektiniz. bu da şu demek oluyor: bu üç kelimenin ilgili yazılımın üç farklı katmanı olduğunu bu durumda anlayabilirdiniz. şimdi tire işaretimiz yok ancak yine de ben kelimelerle tokatlayarak izah ediyorum: model, view ve controller mvc yapısını oluşturan üç ayrı katmandır.

bu katmanlardan model, business logic'i içinde barındırır. ürünün veri çıktısı üretmesi model içindeki prosedürlerle halledilir. view, adı üstünde user interface'i barındırır. yazılımdan istifade eden aktörler (use case diyagramındaki çöp herifler) yalnızca view katmanıyla haşır neşir olurlar. controller ise business logic ve ui arasındaki iletişimi kurmakla görevli güzel bir ablamızdır.

mvc gibi pattern'larda, view ve model birbirinden bağımsız olarak ve düşük bir servis dışı oranıyla kolayca güncellenebilir, böyle de bir güzelliği var.
azureel azureel
ks. mvc
yazılım tasarımında kullanılan, soyutlama ilkesine dayanan bir yapı. modüler programlamaya benzer bir yapısı var sanırım. uygulama algoritmasını, verilerin depolandığı yeri ve birbirleri arasındaki ifade biçimlerini ayırarak; yazılım geliştiriciye tüm bu parçaları diğer kod bölümleri ile oynamadan, tekil olarak düzenleme ve geliştirme fırsatı verebilmesi avantajıdır.

ingilizcede "model-view-controller pattern" olarak geçen konu ise, yazılım geliştirirken, bu soyutlama raconuna uygun şekilde geliştirme yapabilmektir. herhangi bir geliştirici kişi/kurum/kuruluş bu kavramı kendince yorumlayıp, kendine uygun bir bakış açısı ile bu yapıyı icra etmiştir. netten baktığım 5-6 kaynak var ve hepsinde farklı farklı tanımlamalar var, bu rollerin üzerine yüklenen farklı görevler var. ama "tasarım şablonu" olarak türkçeye çevirebileceğimiz design pattern kavramı, bu gibi esnek ve subjektif yoruma açık bir yaklaşımı ne ölçüde kabul eder orası muamma. mvc yaklaşımını, yazılım geliştirilen ortama göre uygulamak şimdilik en iyi çözüm gibi. genel olarak üzerinde anlaşılmış gözüken konuları ise şu şekilde ayıklayabiliriz.

- model
nesne tabanlı yazılımlardaki nesne* veya sınıf* yapısı ile oldukça paralellik gösteren varlıkların kavramsal gösterimidir. uygulamanın gerçeklenmesi sırasında, model sadece varlığın yapısını tanımlıyor da olabilir, illa ki çalışan bir fonksiyon üretilmesi veya tanımlanması gerekmiyor. bununla birlikte nesneye atanmış işlemler (fonksiyon, modül hatta) varsa bunu da içerebilir.

- view
web uygulaması için örneklemek gerekirse, tarayıcıda sayfasının nasıl gözükeceği kısmı viewdır. dinamik içerik (cgi gibi) olması şartı da bulunmamakta ama eğer varsa, bu tip kodlama da view altındadır (model değil).

- controller
model ile view arasındaki bağlantıyı sağlayan kısım. hem nesneleri, hem de görsel ifadesini tutan, ayrıca viewi değiştiren kısım, proses esas olarak burada oluyor aslında.

bir de bu yaklaşım içerisinde business logic olayı var. istanbul yaklaşımı gibi oldu bu ne ya, neyse pattern ve paradigm yerine yaklaşım demeye devam ediyorum; bilenler bilmeyenlere anlatsın. hah business logic, yazılımı satın alan kişinin ondan beklediği işlemin jargondaki ismi olsa gerek. bu işlemleri de fonksiyon/altprogram vb. isimlerle tanımlayabiliriz. bu fonksiyon gerçeklenmesi kısmı da galiba controller aşamasında inceleniyor. ancak azımsanamayacak miktarda kaynakta da "model" kısmı altında "business logic" elemanının dahil edildiğini görebilirsiniz, bu da en başta değindiğim işin görecelilik ve yorumlama kısmı. hatta sırf görsel tasarıma dayanan bir web sitesi projesi var ise, view kısmına tüm business logic yüklenebilir, neden olmasın.

soyutlama mantığını anladıktan sonra, nasıl isimlendirildiğinin sanırım önemi yok. kodu keyfinize göre -ama yazılım mühendisliği prensiplerinden ödün vermeden- yazmak en temizi. (bkz: #2053304)
mustafa mustafa
dallı budaklı, büyük projelerin arapsaçı olmaması için yazılımcıların sıcak bakması gereken yazılım mimarisidir.

programcılar; mvc'nin, kodu uzattığına, gereksiz yere kodun etrafta dolaştırıldığına, yazılımda performans kaybına neden olduğuna inanır. ama inandıkları şeyler doğru değildir.

halbuki, mvc'nin en önemli avantajı gereksiz ve tekrarlayan kısımların oluşmasını engellemek, yazılımın geliştirilmesini ve bakımını hızlandırmaktır; ileride projeya bakıldığında bir şeylerin anlaşılabilir olmasını sağlamaktır.

yazılım; programcının bir gün önce yaptığı kodu hatırlamamaya başladığı andan itibaren yavaş yavaş arapsaçı olma yolunda ilerleyeektir. programcı, yazdığı koda, yine aynı projenin başka bir yerinde ihtiyaç duyduğunda, bu kodun yeniden yazılma ihtimali yüksektir. bu durum gittikçe, içinden çıkılmayacak durumlara yelken açar.

ben ise, v ve c katmalarının iç içe geçirilmesini mantıklı buluyorum. yani her iki katmanı ayrı ayrı düşünmektense, tek gibi düşünerek geliştirmenin bir zararı dokunmayacağını düşünüyorum.
gibigibi gibigibi
microsoft asp.net mvc ile var olmasını sağladığını düşünüyor. oysa bu pattern'in en az 15 senelik geçmişi var. asp.net değil de ruby on rails popüler etti daha çok, sonra da php'ye yayıldı.
lungapausa lungapausa
eski bir web form kullanıcısı olarak, asp.net mvc versiyonuna geçiş yaparken çok zorlandığım pattern. bunda özellikle türkçe kaynakların yetersizliği/kalitesiz oluşu ve dolayısıyla nereden başlayacağını bilememek etkili oldu. piyasadaki cep yakan ve ne çıkacağı belli olmayan kitaplara para vermeden türkçe kaynak üzerinden çalışmak çok kolay değil. yabancı kaynaklarda da, özellikle yapmak istediğin projeye uygun olarak, nasıl başlayacağını bilerek yol çizmesi çok zor oluyor.
e1011001 e1011001
client tarafında da yazılabilir.
yani tarayıcıda çalışacak javascript kodunu spagetti yapmadan model view controller olarak tasarlayabilirsin