MVC Neden Çöktü?
İyi Bir Fikrin Sınırlarına Çarpmak
Yazılım mimarisi tarihin en çok tartışılan konularından biridir. Her dönem kendi sorunlarına çözüm üretmiş, her çözüm zamanla yeni sorunlar doğurmuştur. MVC de bu döngünün içinden geçti — iyi bir fikirdi, ama belirli bir noktanın ötesinde yetersiz kaldı.
Peki MVC neydi, neden bu kadar yaygınlaştı ve sonunda neden terk edildi?
MVC Nedir?
MVC, Model - View - Controller üçlüsünden oluşan bir mimari örüntüdür. 1970'lerde Smalltalk programlama dili çevresinde ortaya çıktı ve onlarca yıl boyunca yazılım dünyasının en yaygın mimari yaklaşımı olarak kaldı.
Fikir temelde şuydu: Uygulamayı üç ayrı sorumluluğa böl.
Model verinin ve iş mantığının yaşadığı yerdir. Veritabanı işlemleri, ağ çağrıları, veri dönüşümleri buraya aittir. Model, UI'dan tamamen habersizdir.
View kullanıcının gördüğü şeydir. Ekrandaki her şey — butonlar, listeler, metinler — View'ın sorumluluğundadır. View yalnızca gösterir, karar vermez.
Controller ikisi arasındaki köprüdür. Kullanıcıdan gelen etkileşimleri alır, Model'e iletir, Model'den gelen sonuçları View'a aktarır.
Kâğıt üzerinde bu ayrım son derece temiz ve mantıklıdır.
Web Dünyasında MVC Neden İşe Yaradı?
MVC'nin en başarılı olduğu ortam web uygulamalarıydı. Ruby on Rails, ASP.NET MVC, Spring MVC — bunların tamamı bu örüntüyü benimsedi ve uzun yıllar boyunca iyi sonuçlar verdi.
Web'de bu ayrım doğaldır çünkü HTTP'nin istek-yanıt döngüsü MVC'nin akışıyla örtüşür. Kullanıcı bir istek gönderir, Controller bu isteği alır, Model'den veriyi çeker, View'ı üretir ve gönderir. Sonra her şey sıfırlanır, bir sonraki istek beklenmeye başlanır.
Bu durumsuz yapı, Controller'ın ne kadar büyüdüğünü bir süreye kadar gizler.
Android'de MVC Nasıl Uygulandı?
Android'de MVC'yi doğal olarak uygulamak için Activity'yi Controller olarak kullanmak mantıklı görünüyordu. Activity hem kullanıcı etkileşimlerini yakalıyordu hem de UI bileşenlerine erişimi vardı.
Ama burada temel bir problem hemen kendini gösterdi: Activity hem Controller hem de View'dı. Layout XML dosyaları View gibi davranıyordu, ama Activity bu layout'u inflate ediyor, View'ları buluyor, onları güncelliyordu. Net bir sınır çizmek mümkün değildi.
Model ayrı tutulabiliyordu — repository sınıfları, veri modelleri ayrı dosyalarda yaşayabiliyordu. Ama Controller ile View arasındaki sınır her zaman bulanıktı.
Massive View Controller: İsimdeki İroni
MVC'nin en meşhur eleştirisi, kısaltmanın ne anlama geldiğine dair yapılan o acı şakadır: Zamanla MVC, Massive View Controller'ın kısaltmasına dönüşüyordu.
Uygulama büyüdükçe Activity'ler şişmeye başlıyordu. Kullanıcı etkileşimleri, ağ çağrıları, veritabanı işlemleri, UI güncellemeleri, animasyon yönetimi, izin kontrolleri — bunların hepsi Activity içinde birikiyordu.
Birkaç ay geliştirilmiş orta büyüklükte bir Android uygulamasında Activity'lerin binlerce satıra ulaşması istisnai değil, olağandı. Bu dosyaları okumak zorlaşıyordu, değiştirmek tehlikeli hale geliyordu, test etmek neredeyse imkânsızlaşıyordu.
Test Edilemezlik: MVC'nin Asıl Kırılma Noktası
MVC'nin en kritik zayıflığı test edilemezliğidir.
Controller yani Activity, Android framework'üne derinden bağımlıdır. Activity'yi test etmek için Android ortamının çalışması gerekir. Bu da her testin gerçek ya da sanal bir cihazda çalıştırılmasını zorunlu kılar. Testler yavaşlar, güvenilirlikleri düşer ve yazılmaları zorlaşır.
Mantık Activity içinde yaşadığı için saf JVM testleri yazılamaz. Mock'lamak güçtür çünkü bağımlılıklar doğrudan Activity içinde oluşturulur ve gizlenir. Bir butona basıldığında tetiklenen iş mantığını izole biçimde test etmek için tüm Activity'yi ayağa kaldırmak gerekir.
Bu tablo sürdürülebilir değildi. Ve bu sürdürülemezliğin farkına varan topluluk yeni arayışlara yöneldi.
MVC'nin Mirası
MVC çöktü demek tamamen haksızlık olur. MVC, sorumluluların ayrılması gerektiği fikrini yazılım topluluğuna kazandırdı. Bu fikir bugün hâlâ geçerliliğini koruyuyor — yalnızca nasıl ayrılacağına dair anlayış olgunlaştı.
MVC'nin getirdiği "Model, UI'dan bağımsız olmalıdır" prensibi, sonraki tüm mimarilerin temel taşı oldu. Sorun MVC'nin fikirlerinde değil, bu fikirlerin Android'in gerçekliğiyle ne kadar uyumlu olduğundaydı.
Ve bu uyumsuzluk MVP'yi doğurdu.