MVC: a Model-View-Controller minta lényege és megvalósítása

Mi az MVC: a Model-View-Controller minta lényege

MVC (Model-View-Controller) — egy architekturális minta, amelyet Trygve Reenskaug javasolt 1979-ben a Smalltalk-80 nyelvhez. A minta három rétegre osztja az alkalmazást: a Model tartalmazza az adatokat és az üzleti logikát, a View a megjelenítésért felel, a Controller feldolgozza a felhasználói bemenetet és frissíti a Model-t és a View-t. A felelősségek szétválasztása lehetővé teszi az egyes rétegek független módosítását — például a View cseréjét UIKit-ről SwiftUI-re anélkül, hogy a Model üzleti logikáját megváltoztatnánk.

Az összetevők interakciója az MVC-ben egy ciklust követ: a felhasználó interakcióba lép a View-val → a Controller fogadja az eseményt → a Controller frissíti a Model-t → a Model értesíti a Controller-t a változásokról → a Controller frissíti a View-t. A klasszikus megvalósításban a Model az Observer mintát használja: az adatok változásakor a Model értesítéseket küld, a Controller feliratkozik és frissíti a View-t. Az Apple megvalósításában a Key-Value Observing (KVO) vagy a NotificationCenter tölti be ezt a szerepet.

Az MVC a modern mobilfejlesztésben ritkábban használatos, mint 10 évvel ezelőtt, de továbbra is kötelező megérteni. Az Apple az MVC-t ajánlja egyszerű képernyőkhöz UIKit alkalmazásokban. A Google nem ajánlja a tiszta MVC-t Androidhoz — a hivatalos dokumentáció az MVVM-et javasolja Jetpack-kel. Az MVC ismerete azonban szükséges az örökölt projektekkel való munkához és az architekturális minták evolúciójának megértéséhez.

MVC iOS-ben: UIViewController és storyboard

Apple MVC — a minta egyedi megvalósítása, amely az UIKit-be van építve. Az UIViewController a Controller szerepét tölti be: kezeli a képernyő életciklusát (viewDidLoad, viewWillAppear, viewDidDisappear), feldolgozza az érintéseket és a felhasználói műveleteket, frissíti a View-t IBOutlets-en keresztül. A View az Interface Builder-ben (storyboard vagy XIB) vagy programozottan jön létre. A Model — bármilyen adatobjektum: hálózati szolgáltatások, CoreData vermek, Swift struktúrák.

final class UserViewController: UIViewController {
    // View (storyboard outlet-en keresztül)
    @IBOutlet private var nameLabel: UILabel!
    @IBOutlet private var emailLabel: UILabel!

    // Model
    private let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        loadUser()
    }

    private func loadUser() {
        userService.fetchUser { [weak self] user in
            // Controller frissíti a View-t
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

Az Apple MVC problémája — a View és a Controller szorosan kapcsolódik. Az UIViewController egyszerre kezeli a View-t és a logikát. A Storyboard XML-ben tárolja a View-t, de a vezérlőnek közvetlen hivatkozásai vannak az UI elemekre IBOutlets-en keresztül. Ez sérti az egyetlen felelősség elvét: a vezérlő felelős az életciklusért, delegáltakért, datasource-ért, target-action-ért és animációkért. Ennek eredményeként egy iOS alkalmazás szabványos képernyője 200–500 sort tartalmaz a vezérlőben.

A ViewController életciklusa — az Apple 6 életciklus metódust biztosít: loadView (a View kézi létrehozása), viewDidLoad (a View memóriába való betöltése után), viewWillAppear (a képernyőn való megjelenés előtt), viewDidAppear (animáció után), viewWillDisappear (a képernyő elhagyása előtt), viewDidDisappear (elhagyás után). Minden metódus — egy hely a logika elhelyezésére az MVC-ben. E metódusok használata üzleti logikához felgyorsítja a vezérlő növekedését.

MVC Androidban: Activity, Fragment és XML elrendezés

Android MVC — az Activity és Fragment tölti be a Controller szerepét, az XML elrendezési fájlok — View, bármely POJO osztály adatokkal — Model. Az Activity kezeli a képernyő életciklusát: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment — alképernyő az Activity-n belül saját életciklussal. A View (XML) el van választva a Controller-től, és a setContentView vagy LayoutInflater segítségével töltődik be. Model — adattárak, adatbázisok, hálózati hívások.

class UserActivity : AppCompatActivity() {
    // View XML elrendezésen keresztül
    private lateinit var binding: ActivityUserBinding

    // Model
    private val userRepository = UserRepository()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityUserBinding.inflate(layoutInflater)
        setContentView(binding.root)
        loadUser()
    }

    private fun loadUser() {
        userRepository.getUser { user ->
            runOnUiThread {
                binding.nameText.text = user.name
                binding.emailText.text = user.email
            }
        }
    }
}

Android ViewBinding és DataBinding — modern eszközök, amelyek csökkentik a Controller és a View közötti kapcsolódást. A ViewBinding egy osztályt generál közvetlen hivatkozásokkal a View-ra XML-ből, megszüntetve a findViewById-t. A DataBinding hozzáadja a lehetőséget az adatok UI-hoz való kötésére XML jelölésben a @{user.name} segítségével. A DataBinding — egy lépés az MVVM felé, mivel lehetővé teszi az adatok átvitelét a Model-ből a View-ba kód nélkül az Activity-ben. A Google a DataBinding-et ajánlja minden új projekthez.

Az Android életciklusa összetettebb, mint az iOS-é: az Activity megsemmisíthető és újra létrehozható a képernyő elforgatásakor, memóriahiány vagy konfigurációváltozás esetén. A tiszta MVC-ben a vezérlő (Activity) olyan logikát tartalmaz, amely elvész a megsemmisítéskor. Ez megköveteli az állapot mentését onSaveInstanceState vagy ViewModel segítségével a Jetpack-ből, ami túlmutat a tiszta MVC keretein és közelebb hozza az architektúrát az MVVM-hez.

Massive View Controller és az MVC korlátai

Massive View Controller — egy kifejezés, amely az MVC fő problémáját írja le a mobilfejlesztésben. A vezérlő iOS-ben és Androidban túl sok felelősséget vállal magára: bemenet feldolgozása, adatérvényesítés, hálózati interakció, navigáció, gyorsítótárazás, animációk, életciklus-kezelés. Ennek eredményeként a vezérlő 500–2000 sorosra nő, nehézzé válik olvasni, tesztelni és karbantartani.

A Massive View Controller okai — az UIKit és Android Framework architektúrája ösztönzi a logika vezérlőbe helyezését. Hálózati hívások, JSON feldolgozás, navigáció — mindez természetesen az Activity-ben vagy UIViewController-ben íródik, mivel hozzáférnek az életciklushoz és az UI-hoz. A fejlesztőnek tudatosan kell kiszerveznie a logikát külön osztályokba (Service, Manager, Interactor), ami fegyelmet és az architekturális elvek megértését igényli.

Az MVC tesztelése — a Model elkülönítve tesztelhető egységtesztekkel. A Controller-t nehéz tesztelni az UIKit/UIFoundation-től való függőség miatt. Az XCTest nem teszi lehetővé UIViewController létrehozását megjelenítési ablak nélkül. Androidhoz az ActivityTestRule és Robolectric részben megoldja a problémát, de a tesztek lassúak. A View-t általában nem tesztelik egységtesztekkel — az UI-hoz képernyőkép- és UI teszteket (XCUITest, Espresso) használnak.

Mikor indokolt az MVC — egyszerű képernyők egy-két elemmel (bejelentkezési képernyő, profil, beállítások). Prototípusok és MVP hipotézisek teszteléséhez — az MVC gyorsabban írható további rétegek nélkül. Kis kódbázisú projektek 10–15 képernyőig. Összetett projektekben az MVC technikai adósság felhalmozódásához vezet, és 6–12 havonta refaktorálást igényel.

Az MVC összehasonlítása az MVVM-mel, MVP-vel és Clean Architecture-szel

MVC vs MVVM — a fő különbség: az MVVM-ben a vezérlőt ViewModel váltja fel, amely nem rendelkezik hivatkozással a View-ra. Az adatok Observable (SwiftUI), LiveData/StateFlow (Android) vagy Combine/RxSwift segítségével kerülnek átvitelre. A ViewModel egységtesztekkel tesztelhető UI függőségek nélkül. Az Apple 2019 óta az MVVM-et ajánlja SwiftUI-val, a Google — az MVVM-et LiveData/Flow-val az Android hivatalos architektúrájaként. Az MVVM több kódot igényel a kötéshez, de jelentősen javítja a tesztelhetőséget.

MVC vs MVP — az MVP-ben (Model-View-Presenter) a Presenter egy tesztelhető réteg, amely interfészen keresztül kapja a View-t. Ellentétben az MVC-vel, ahol a Controller közvetlenül kezeli a View-t az UIKit-en keresztül, a Presenter nem függ a keretrendszertől — a ViewInterface absztrakción keresztül működik. Az MVP népszerű volt az Android fejlesztésben a Jetpack megjelenése előtt, és régi projektekben használatos. A Presenter tovább él, mint az Activity, és megőrzi az állapotot a képernyő elforgatásakor.

MVC vs Clean Architecture — a Clean Architecture hozzáadja a Use Cases (Interactors), Entities, Gateways és Repository rétegeket. Az MVC a Presentation rétegben marad, de az üzleti logika a Domain rétegbe kerül Use Cases-szel. A Clean Architecture radikálisan megoldja a Massive View Controller problémáját — a Controller csak Use Cases hívásokat és a View frissítését tartalmazza. Hátránya az osztályok és fájlok számának jelentős növekedése, ami 50+ képernyős projekteknél indokolt.

// MVC iOS-ben: Controller mindent tartalmaz
class OrderViewController: UIViewController {
    func placeOrder() {
        // Érvényesítés + hálózat + UI frissítés
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: logika a ViewModel-ben
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* üzleti logika */ }
}

Architektúra választása a csapat méretétől, a projekttől és a szükséges tesztelhetőségtől függ. 1–2 fejlesztőből álló csapat és 20 képernyőig terjedő projekt esetén az MVVM megfelelő. 5 fejlesztőből álló nagy csapat és 50 képernyőtől induló projekt esetén — Clean Architecture moduláris szerkezettel. Az MVC továbbra is releváns az architektúrák evolúciójának megértéséhez, az örökölt projektek támogatásához és az egyszerű, összetett üzleti logika nélküli UIKit képernyőkhöz.