MVC: Model-View-Controller nümunəsinin mahiyyəti və onun tətbiqi

MVC nədir: Model-View-Controller nümunəsinin mahiyyəti

MVC (Model-View-Controller) — 1979-cu ildə Trygve Reenskaug tərəfindən Smalltalk-80 dili üçün təklif edilmiş arxitektura nümunəsidir. Nümunə proqramı üç təbəqəyə bölür: Model məlumatları və biznes məntiqini ehtiva edir, View göstərimə cavabdehdir, Controller istifadəçi girişini emal edir və Model ilə View-i yeniləyir. Məsuliyyətin bölünməsi hər təbəqəni müstəqil dəyişməyə imkan verir — məsələn, UIKit-dən SwiftUI-ə View-i dəyişmək Model-də biznes məntiqini dəyişmədən.

Komponentlərin qarşılıqlı əlaqəsi MVC-də dövrü izləyir: istifadəçi View ilə qarşılıqlı əlaqədə olur → Controller hadisəni alır → Controller Model-i yeniləyir → Model dəyişikliklər barədə Controller-ə məlumat verir → Controller View-i yeniləyir. Klassik tətbiqdə Model Observer nümunəsindən istifadə edir: məlumatlar dəyişdikdə Model bildirişlər göndərir, Controller abunə olur və View-i yeniləyir. Apple tətbiqində Key-Value Observing (KVO) və ya NotificationCenter bu rolu oynayır.

MVC müasir mobil inkişafda 10 il əvvəlkindən daha az istifadə olunur, lakin başa düşülməsi məcburidir. Apple sadə UIKit ekranları üçün MVC tövsiyə edir. Google Android üçün təmiz MVC tövsiyə etmir — rəsmi sənədlər MVVM-i Jetpack ilə təklif edir. Lakin MVC bilikləri legacy layihələrlə işləmək və arxitektura nümunələrinin təkamülünü başa düşmək üçün zəruridir.

iOS-da MVC: UIViewController və storyboard

Apple MVC — UIKit-ə quraşdırılmış nümunənin xüsusi tətbiqidir. UIViewController Controller rolunu oynayır: ekranın həyat dövrünü idarə edir (viewDidLoad, viewWillAppear, viewDidDisappear), toxunuşları və istifadəçi hərəkətlərini emal edir, IBOutlets vasitəsilə View-i yeniləyir. View Interface Builder-də (storyboard və ya XIB) və ya proqramlı şəkildə yaradılır. Model — hər hansı məlumat obyektləridir: şəbəkə servisləri, CoreData yığınları, Swift strukturları.

final class UserViewController: UIViewController {
    // View (storyboard outlet vasitəsilə)
    @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 View-i yeniləyir
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

Apple MVC-nin problemi — View və Controller sıx bağlıdır. UIViewController eyni anda həm View-i, həm də məntiqi idarə edir. Storyboard View-i XML-də saxlayır, lakin kontroller IBOutlets vasitəsilə UI elementlərinə birbaşa istinadlara malikdir. Bu, tək məsuliyyət prinsipini pozur: kontroller həyat dövrü, delegatlar, datasource, target-action və animasiyalara cavabdehdir. Nəticədə iOS proqramının standart ekranı kontrollerdə 200–500 sətir ehtiva edir.

ViewController həyat dövrü — Apple 6 həyat dövrü metodu təqdim edir: loadView (View-in əl ilə yaradılması), viewDidLoad (View yaddaşa yükləndikdən sonra), viewWillAppear (ekranda görünməzdən əvvəl), viewDidAppear (animasiyadan sonra), viewWillDisappear (ekrandan çıxmazdan əvvəl), viewDidDisappear (çıxdıqdan sonra). Hər metod MVC-də məntiqin yerləşdirilməsi üçün yerdir. Bu metodlardan biznes məntiqi üçün istifadə kontrollerin böyüməsini sürətləndirir.

Android-də MVC: Activity, Fragment və XML layout

Android MVC — Activity və Fragment Controller rolunu oynayır, XML layout faylları — View, məlumatlarla hər hansı POJO sinfi — Model. Activity ekranın həyat dövrünü idarə edir: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment — Activity daxilində öz həyat dövrü olan alt ekrandır. View (XML) Controller-dən ayrılıb və setContentView və ya LayoutInflater vasitəsilə yüklənir. Model — repozitoriyalar, verilənlər bazaları, şəbəkə çağırışları.

class UserActivity : AppCompatActivity() {
    // XML layout vasitəsilə View
    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 və DataBinding — Controller və View arasında bağlılığı azaldan müasir alətlərdir. ViewBinding XML-dən View-ə birbaşa istinadlarla sinif yaradır, findViewById-i aradan qaldırır. DataBinding məlumatları UI ilə XML işarələməsində @{user.name} vasitəsilə birləşdirmək imkanı əlavə edir. DataBinding — MVVM-ə doğru addımdır, çünki Activity-də kod olmadan Model-dən View-ə məlumat ötürməyə imkan verir. Google bütün yeni layihələr üçün DataBinding tövsiyə edir.

Android həyat dövrü iOS-dan daha mürəkkəbdir: Activity ekranın döndərilməsi, yaddaş çatışmazlığı və ya konfiqurasiya dəyişikliyi zamanı məhv edilə və yenidən yaradıla bilər. Təmiz MVC-də kontroller (Activity) məhv edildikdə itən məntiq ehtiva edir. Bu, onSaveInstanceState və ya Jetpack-dən ViewModel vasitəsilə vəziyyətin qorunmasını tələb edir ki, bu da təmiz MVC-nin çərçivəsindən kənara çıxır və arxitekturanı MVVM-ə yaxınlaşdırır.

Massive View Controller və MVC-nin məhdudiyyətləri

Massive View Controller — mobil inkişafda MVC-nin əsas problemini təsvir edən termindir. iOS və Android-də kontroller çoxlu öhdəliklər götürür: girişin işlənməsi, məlumatların validasiyası, şəbəkə qarşılıqlı əlaqəsi, naviqasiya, keşləmə, animasiyalar, həyat dövrünün idarə edilməsi. Nəticədə kontroller 500–2000 sətirə qədər böyüyür, oxunması, test edilməsi və saxlanması çətinləşir.

Massive View Controller-ın səbəbləri — UIKit və Android Framework arxitekturası məntiqin kontrollerdə yerləşdirilməsini təşviq edir. Şəbəkə çağırışları, JSON-un işlənməsi, naviqasiya — bütün bunlar təbii olaraq Activity və ya UIViewController-də yazılır, çünki onlar həyat dövrünə və UI-ə çıxışa malikdirlər. Tərtibatçı şüurlu şəkildə məntiqi ayrı siniflərə (Service, Manager, Interactor) çıxarmalıdır ki, bu da intizam və arxitektura prinsiplərini başa düşməyi tələb edir.

MVC-nin test edilməsi — Model unit testlərlə təcrid olunmuş şəkildə test edilir. Controller-i UIKit/UIFoundation-dan asılılığa görə test etmək çətindir. XCTest pəncərəsi olmayan UIViewController yaratmağa imkan vermir. Android üçün ActivityTestRule və Robolectric qismən problemi həll edir, lakin testlər yavaşdır. View adətən unit testlərlə test edilmir — UI üçün ekran görüntüsü və UI testləri (XCUITest, Espresso) tətbiq olunur.

MVC nə vaxt əsaslandırılır — bir-iki elementdən ibarət sadə ekranlar (giriş ekranı, profil, parametrlər). Fərziyyələrin yoxlanılması üçün prototiplər və MVP — MVC əlavə təbəqələr olmadan daha sürətli yazılır. 10–15 ekrana qədər kiçik kod bazası olan layihələr. Mürəkkəb layihələrdə MVC texniki borcun yığılmasına gətirib çıxarır və hər 6–12 aydan bir refaktorinq tələb edir.

MVC-nin MVVM, MVP və Clean Architecture ilə müqayisəsi

MVC vs MVVM — əsas fərq: MVVM-də kontroller View-ə istinadı olmayan ViewModel ilə əvəz olunur. Məlumatlar Observable (SwiftUI), LiveData/StateFlow (Android) və ya Combine/RxSwift vasitəsilə ötürülür. ViewModel UI asılılıqları olmadan unit testlərlə test edilir. Apple 2019-cu ildən MVVM-i SwiftUI ilə tövsiyə edir, Google — MVVM-i LiveData/Flow ilə Android-in rəsmi arxitekturası kimi. MVVM bağlama üçün daha çox kod tələb edir, lakin test olunma qabiliyyətini əhəmiyyətli dərəcədə yaxşılaşdırır.

MVC vs MVP — MVP-də (Model-View-Presenter) Presenter interfeys vasitəsilə View-i alan test olunan təbəqədir. MVC-dən fərqli olaraq, Controller UIKit vasitəsilə birbaşa View-i idarə edir, Presenter freymvorkdan asılı deyil — ViewInterface abstraksiyası vasitəsilə işləyir. MVP Jetpack-in meydana çıxmasına qədər Android inkişafında populyar idi və köhnə layihələrdə istifadə olunur. Presenter Activity-dən daha uzun yaşayır və ekran döndərildikdə vəziyyəti qoruyur.

MVC vs Clean Architecture — Clean Architecture Use Cases (Interactors), Entities, Gateways və Repository təbəqələrini əlavə edir. MVC Presentation təbəqəsində qalır, lakin biznes məntiqi Use Cases ilə Domain təbəqəsinə çıxarılır. Clean Architecture Massive View Controller problemini köklü şəkildə həll edir — Controller yalnız Use Cases çağırışlarını və View-in yenilənməsini ehtiva edir. Çatışmazlıq — siniflərin və faylların sayının əhəmiyyətli dərəcədə artması, bu da 50+ ekranlı layihələr üçün əsaslandırılır.

// iOS-da MVC: Controller hər şeyi ehtiva edir
class OrderViewController: UIViewController {
    func placeOrder() {
        // Validasiya + şəbəkə + UI yeniləmə
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: məntiq ViewModel-də
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* biznes məntiqi */ }
}

Arxitektura seçimi komandanın ölçüsündən, layihədən və tələb olunan test olunma qabiliyyətindən asılıdır. 1–2 tərtibatçıdan ibarət komanda və 20 ekrana qədər layihə üçün MVVM uyğundur. 5 tərtibatçıdan ibarət böyük komanda və 50 ekrandan layihə üçün — modul strukturu ilə Clean Architecture. MVC aktual qalır arxitekturaların təkamülünü başa düşmək, legacy layihələri dəstəkləmək və mürəkkəb biznes məntiqi olmayan UIKit-də sadə ekranlar üçün.