Cevap.

Sorunun Tarihçesi

Model-View-Controller (MVC) deseni, verileri, kullanıcı arayüzünü ve yönetim mantığını ayırmak için kullanılan klasik bir mimari desen olup, Swift'ten çok önce ortaya çıkmıştır. iOS geliştirme tarihindeki MVC, Apple tarafından Objective-C ve Swift uygulamaları oluşturmak için ana mimari desen olarak ilan edilmiştir.

Sorun

Standart MVC'nin temel sorunu, zamanla kontrolörlerin "Büyük Görüntü Kontrolörleri" haline gelmesi ve iş mantığını, model ile etkileşimi, kullanıcı girişi işlemlerini ve hatta görüntüleme mantığını bir araya getirmesidir. Bu, kodun okunabilirliğini, yeniden kullanılabilirliğini ve test edilebilirliğini azaltır.

Çözüm

Swift'te MVC, kontrolör için UIViewController sınıflarını, modeller için yapı veya sınıf olarak ve kullanıcı arayüzü oluşturmak için UIView kullanılarak uygulanır. Kontrolör, model ile görünümü birleştirir ve verilerdeki değişiklikler olduğunda kullanıcı arayüzünü güncelleyerek başlatır.

Kod örneği:

struct User {
    let name: String
    let age: Int
}

class UserView: UIView {
    let nameLabel = UILabel()
    func display(user: User) {
        nameLabel.text = "\(user.name), \(user.age) yaşında"
    }
}

class UserController: UIViewController {
    var user: User?
    var userView: UserView!

    override func loadView() {
        userView = UserView()
        view = userView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        if let user = user {
            userView.display(user: user)
        }
    }
}

Anahtar özellikler:

Katmanlar arasındaki bağlantı kontrolör aracılığıyla yapılır.
Model görünümü bilmez.
Kullanıcı girişi ve yönlendirme mantığı kontrolörde yer alır.

Aldatıcı Sorular.

MVC'de Görünüm ve Model arasında doğrudan bağımlılık izin verilebilir mi?

Hayır, Görünüm Model ile doğrudan etkileşimde bulunmamalıdır. Tüm iletişim yalnızca Kontrolör aracılığıyla gerçekleşir; aksi takdirde model "görünümü" bilmeye başlar, bu da sorumluluğun ayrımı ilkesini ihlal eder ve ölçeklenebilirliği zorlaştırır.

Kontrolör iş seviyesindeki veri ve mantığı içerebilir mi?

Kontrolörün iş mantığını içerebileceği sıklıkla yanlış anlaşılmaktadır. Aslında, iş mantığını Model veya ayrı servislerde tutmak gerekir; kontrolör yalnızca Görünümün yaşam döngüsünü yönetmeli ve verilerin uyumunu sağlamalıdır.

Büyük kontrolörlerle (Büyük Görüntü Kontrolörü) nasıl başa çıkılır?

Büyük kontrolörlerle başa çıkmak için veri işleme işlemlerini kontrolörden Model veya servislere taşıyın, delegeler, delegasyon ve kompozisyon desenlerini kullanın. Görünümü yapılandırmak için ayrı sınıflar oluşturun veya görüntüleme mantığını doğrudan Görünüm içine koyun.

Tipik hatalar ve antipatiler

Model doğrudan Görünüm ile iletişim kurar
Büyük kontrolör (Büyük Görüntü Kontrolörü)
Kontrolörde Görünüm durumunu tutmak
İş mantığının Model'de ayrıştırılmaması

Gerçek Hayat Örneği

Olumsuz Durum

Projede kontrolör, hem kullanıcı verilerini hem de bunların işlenmesini ve görüntüleme kodunu bir arada tutuyordu. Başka bir kontrolörde bu mantığı yeniden kullanmak imkansız oldu ve iş mantığını test etmek oldukça zor geldi.

Artılar:

Hızlı başlangıç, az sayıda sınıf

Eksiler:

Okunması zor kod
Bakım ve test etmede zorluklar

Olumlu Durum

Model yalnızca veri ve iş mantığından sorumlu, Görünüm arayüzü çizer, Kontrolör bunları bağlar. Bileşenleri yeniden kullanma, test etme ve uygulamayı daha hızlı ölçeklendirme imkanı doğmuştur.