PHP MVC nedir?

PHP MVC, bir web uygulamasının kodunu Model, View ve Controller olarak üç sorumluluk alanına ayıran bir yazılım mimarisi yaklaşımıdır. PHP’nin kendi içinde zorunlu olarak sunduğu bir özellik değildir; uygulamayı daha düzenli, test edilebilir ve sürdürülebilir kurmak için kullanılan bir tasarım biçimidir.

MVC bileşenleri nasıl çalışır?​

• Model: Veriye ve iş kurallarına erişir. Örneğin ürünleri veritabanından almak, stok kontrolü yapmak veya sipariş toplamını hesaplamak model katmanının işidir.
• View: Kullanıcıya gösterilecek çıktıyı üretir. HTML şablonu, tablo veya form genellikle bu katmanda bulunur. Veritabanı sorgusu ve karmaşık iş kuralları burada yapılmamalıdır.
• Controller: İsteği karşılar, gerekli girdileri alır, uygun model işlemini çağırır ve sonucu uygun view’a gönderir.
  

Tipik akış şöyledir: Kullanıcı bir URL’ye istek gönderir, yönlendirici bu isteği bir controller metoduna aktarır, controller modelden veri alır ve veriyi view’a vererek yanıtı oluşturur. Bazı uygulamalarda yönlendirme, doğrulama ve yanıt biçimlendirme için ayrıca servis veya middleware katmanları da bulunabilir; bunlar MVC’nin temel üç parçasına ek sorumluluk katmanlarıdır.

Somut örnek: ürün ayrıntı sayfası​

Varsayımsal olarak kullanıcı /urun/42 adresini açsın. Uygulama bu isteği şöyle işler:

1. Router, /urun/42 isteğini ProductController::show(42) metoduna yönlendirir.
2. Controller, ürün kimliğinin geçerli olup olmadığını kontrol eder ve ProductModel üzerinden 42 numaralı ürünü ister.
3. Model veritabanından ürünü alır; ürün yoksa bunu controller’a bildirir.
4. Controller ürün verisini products/detail.php view’ına aktarır.
5. View ürün adını, fiyatını ve açıklamasını HTML olarak gösterir.
6. Ürün bulunamadığında controller, 404 durum koduyla uygun hata yanıtı döndürür; HTML görünümü bu yanıtın gövdesi olabilir.

Buradaki önemli nokta, view’ın veriyi nasıl göstereceğini; modelin ise verinin nereden ve hangi kuralla alınacağını bilmesidir. Controller bu iki tarafı birbirine bağlar, fakat bütün uygulama mantığının toplandığı sınırsız bir dosyaya dönüşmemelidir.

Dosya sorumluluklarını ayırma​

Küçük bir projede aşağıdaki gibi bir yapı yeterli bir başlangıç olabilir:


Bu yapıdaki adlar zorunlu değildir. Önemli olan, dosyanın adına değil sorumluluğuna göre yerleştirilmesidir. Örneğin bir SQL sorgusunu view içine yazmak veya HTML çıktısını modelden döndürmek MVC ayrımını zayıflatır.

MVC’nin pratikte hangi sorunu çözdüğünü şu karşılaştırma gösterir:


Bu ayrım özellikle aynı veriyi farklı biçimlerde sunarken yararlıdır. Ürün modeli web sayfası, JSON yanıtı veya yönetim paneli tarafından kullanılabilir; her çıktı biçimi için ayrı controller ve view mantığı kurulabilir.

PHP projesinde uygulanabilir kararlar​

1. Önce gelen URL ile hangi işlemin yapılacağını belirleyin ve bunu bir controller eylemine bağlayın.
2. Controller’da kimlik doğrulama, temel girdi kontrolü ve akış kararlarını yapın; karmaşık iş kurallarını servis veya model katmanına taşıyın.
3. Veritabanı erişimini model ya da ayrı bir veri erişim sınıfında toplayın. Kullanıcı girdilerini sorguya doğrudan birleştirmeyin; parametreli sorgu kullanın.
4. View’a yalnızca görüntüleme için gereken veriyi aktarın. HTML çıktısında kullanıcıdan gelen değerleri uygun şekilde kaçışlayın.
5. Bir katmanın sorumluluğu büyüdüğünde yeni sınıflara ayırın; sırf MVC adına gereksiz sayıda dosya oluşturmayın.

Sık yapılan hatalar​

En yaygın hata, MVC’yi yalnızca üç klasör oluşturmak sanmaktır. Klasör adlarını değiştirmek tek başına mimari ayrım sağlamaz. Asıl ölçüt, her katmanın tek ve anlaşılır bir sorumluluğa sahip olmasıdır.

Diğer bir hata da controller’ı her işin yapıldığı bir “toplayıcı” sınıfa dönüştürmektir. Controller yalnızca isteği koordine etmeli; sipariş hesaplama, stok düşme veya bildirim gönderme gibi bağımsız kurallar gerektiğinde servis sınıflarına ayrılmalıdır. Ayrıca modelin yalnızca veritabanı tablosu karşılığı olduğu düşünülmemelidir; iş kuralları uygun bir model veya servis katmanında bulunabilir.

Sık sorulan sorular​

JSON API’de HTML view yoksa MVC kullanılamaz mı?​

Çıktı HTML olmak zorunda değildir. Bir API veriyi JSON temsiline dönüştürebilir; istek koordinasyonu ve iş kuralları yine ayrılabilir. Framework’ün response veya serializer bileşeni bu sunum sorumluluğunu taşıyabilir. Yalnız klasör adının Views olması mimari doğruluk ölçüsü değildir.

Ödeme hesabını test etmek için bütün HTTP uygulamasını başlatmak gerekir mi?​

İş kuralı framework ve istek ayrıntılarından ayrılmışsa çoğu temel kural doğrudan küçük girdilerle sınanabilir. Controller’ın girdiyi doğru aktarması ve view’ın doğru çıktıyı üretmesi ise ayrıca test edilir. Ayrımın yararı, tek hata için bütün katmanları aynı anda değiştirmek zorunda kalmamaktır.