MVC: Model-View-Controller na'munasining mohiyati va uning tatbiqi

MVC nima: Model-View-Controller na'munasining mohiyati

MVC (Model-View-Controller) — 1979-yilda Trygve Reenskaug tomonidan Smalltalk-80 tili uchun taklif qilingan arxitektura na'munasidir. Na'muna dasturni uch qatlamga ajratadi: Model ma'lumotlar va biznes mantiqini o'z ichiga oladi, View ko'rsatish uchun javobgar, Controller foydalanuvchi kirishini qayta ishlaydi va Model bilan View'ni yangilaydi. Mas'uliyatning bo'linishi har bir qatlamni mustaqil o'zgartirishga imkon beradi — masalan, UIKit'dan SwiftUI'ga View'ni Model'dagi biznes mantiqini o'zgartirmasdan almashtirish.

Komponentlarning o'zaro ta'siri MVC'da sikl bo'ylab boradi: foydalanuvchi View bilan o'zaro ta'sir qiladi → Controller hodisani oladi → Controller Model'ni yangilaydi → Model o'zgarishlar haqida Controller'ga xabar beradi → Controller View'ni yangilaydi. Klassik tatbiqda Model Observer na'munasidan foydalanadi: ma'lumotlar o'zgarganda Model bildirishnomalar yuboradi, Controller obuna bo'ladi va View'ni yangilaydi. Apple tatbiqida Key-Value Observing (KVO) yoki NotificationCenter bu rolni o'ynaydi.

MVC zamonaviy mobil rivojlanishda 10 yil oldingiga qaraganda kamroq qo'llaniladi, lekin tushunilishi majburiydir. Apple oddiy UIKit ekranlari uchun MVC'ni tavsiya qiladi. Google Android uchun toza MVC'ni tavsiya etmaydi — rasmiy hujjatlar Jetpack bilan MVVM'ni taklif qiladi. Biroq, MVC bilimlari legacy loyihalar bilan ishlash va arxitektura na'munalarining evolyutsiyasini tushunish uchun zarurdir.

iOS'da MVC: UIViewController va storyboard

Apple MVC — UIKit'ga o'rnatilgan na'munaning maxsus tatbiqidir. UIViewController Controller rolini o'ynaydi: ekranning hayotiy siklini boshqaradi (viewDidLoad, viewWillAppear, viewDidDisappear), teginishlar va foydalanuvchi harakatlarini qayta ishlaydi, IBOutlets orqali View'ni yangilaydi. View Interface Builder'da (storyboard yoki XIB) yoki dasturiy ravishda yaratiladi. Model — har qanday ma'lumot ob'yektlari: tarmoq servislari, CoreData steklari, Swift tuzilmalari.

final class UserViewController: UIViewController {
    // View (storyboard outlet orqali)
    @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'ni yangilaydi
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

Apple MVC muammosi — View va Controller qattiq bog'langan. UIViewController bir vaqtning o'zida ham View'ni, ham mantiqni boshqaradi. Storyboard View'ni XML'da saqlaydi, lekin kontroller IBOutlets orqali UI elementlariga to'g'ridan-to'g'ri havolalarga ega. Bu yagona mas'uliyat prinsipini buzadi: kontroller hayotiy sikl, delegatlar, datasource, target-action va animatsiyalar uchun javobgardir. Natijada iOS dasturining standart ekrani kontrollerda 200–500 qatorni o'z ichiga oladi.

ViewController hayotiy sikli — Apple 6 hayotiy sikl usulini taqdim etadi: loadView (View'ni qo'lda yaratish), viewDidLoad (View xotiraga yuklangandan so'ng), viewWillAppear (ekranda paydo bo'lishdan oldin), viewDidAppear (animatsiyadan so'ng), viewWillDisappear (ekrandan chiqishdan oldin), viewDidDisappear (chiqqandan so'ng). Har bir usul MVC'da mantiqni joylashtirish uchun joy. Bu usullardan biznes mantiqi uchun foydalanish kontrollerning o'sishini tezlashtiradi.

Android'da MVC: Activity, Fragment va XML layout

Android MVC — Activity va Fragment Controller rolini o'ynaydi, XML layout fayllari — View, ma'lumotlar bilan har qanday POJO sinfi — Model. Activity ekranning hayotiy siklini boshqaradi: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment — Activity ichida o'z hayotiy sikliga ega osti ekrani. View (XML) Controller'dan ajratilgan va setContentView yoki LayoutInflater orqali yuklanadi. Model — repozitoriylar, ma'lumotlar bazalari, tarmoq chaqiruvlari.

class UserActivity : AppCompatActivity() {
    // View XML layout orqali
    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 va DataBinding — Controller va View o'rtasidagi bog'liqlikni kamaytiruvchi zamonaviy vositalardir. ViewBinding XML'dan View'ga to'g'ridan-to'g'ri havolalar bilan sinf yaratadi, findViewById'ni yo'q qiladi. DataBinding ma'lumotlarni UI bilan XML belgilashda @{user.name} orqali bog'lash imkoniyatini qo'shadi. DataBinding — MVVM tomon qadam, chunki Activity'da kod bo'lmagan holda ma'lumotlarni Model'dan View'ga o'tkazish imkonini beradi. Google barcha yangi loyihalar uchun DataBinding'ni tavsiya qiladi.

Android hayotiy sikli iOS'dan murakkabroq: Activity ekran aylantirilganda, xotira yetishmasligida yoki konfiguratsiya o'zgarganda yo'q qilinishi va qayta yaratilishi mumkin. Toza MVC'da kontroller (Activity) yo'q qilinganda yo'qoladigan mantiqni o'z ichiga oladi. Bu onSaveInstanceState yoki Jetpack'dan ViewModel orqali holatni saqlashni talab qiladi, bu esa toza MVC doirasidan tashqariga chiqadi va arxitekturni MVVM'ga yaqinlashtiradi.

Massive View Controller va MVC cheklovlari

Massive View Controller — mobil rivojlanishda MVC'ning asosiy muammosini tavsiflovchi termindir. iOS va Android'da kontroller juda ko'p majburiyatlarni o'z zimmasiga oladi: kirishni qayta ishlash, ma'lumotlarni validatsiya qilish, tarmoq bilan o'zaro ta'sir, navigatsiya, keshlashtirish, animatsiyalar, hayotiy siklini boshqarish. Natijada kontroller 500–2000 qatorgacha o'sadi, o'qish, test qilish va qo'llab-quvvatlash qiyinlashadi.

Massive View Controller sabablari — UIKit va Android Framework arxitekturasi mantiqni kontrollerda joylashtirishni rag'batlantiradi. Tarmoq chaqiruvlari, JSON'ni qayta ishlash, navigatsiya — bularning barchasi tabiiy ravishda Activity yoki UIViewController'da yoziladi, chunki ular hayotiy sikl va UI'ga kirish imkoniyatiga ega. Dasturchi ongli ravishda mantiqni alohida sinflarga (Service, Manager, Interactor) chiqarishi kerak, bu intizom va arxitektura prinsiplarini tushunishni talab qiladi.

MVC'ni test qilish — Model alohida unit testlar bilan sinovdan o'tkaziladi. Controller'ni UIKit/UIFoundation'ga bog'liqligi sababli test qilish qiyin. XCTest oynasiz UIViewController yaratishga ruxsat bermaydi. Android uchun ActivityTestRule va Robolectric qisman muammoni hal qiladi, lekin testlar sekin. View odatda unit testlar bilan tekshirilmaydi — UI uchun ekran tasviri va UI testlari (XCUITest, Espresso) qo'llaniladi.

MVC qachon asoslanadi — bir-ikki elementdan iborat oddiy ekranlar (kirish ekrani, profil, sozlamalar). Gipotezalarni tekshirish uchun prototiplar va MVP — MVC qo'shimcha qatlamlarsiz tezroq yoziladi. 10–15 ekrangacha kichik kod bazasiga ega loyihalar. Murakkab loyihalarda MVC texnik qarzning to'planishiga olib keladi va har 6–12 oyda refaktoringni talab qiladi.

MVC'ni MVVM, MVP va Clean Architecture bilan solishtirish

MVC vs MVVM — asosiy farq: MVVM'da kontroller View'ga havolasi bo'lmagan ViewModel bilan almashtiriladi. Ma'lumotlar Observable (SwiftUI), LiveData/StateFlow (Android) yoki Combine/RxSwift orqali uzatiladi. ViewModel UI bog'liqliklarisiz unit testlar bilan tekshiriladi. Apple 2019-yildan MVVM'ni SwiftUI bilan tavsiya qiladi, Google — MVVM'ni LiveData/Flow bilan Android'ning rasmiy arxitekturasi sifatida. MVVM bog'lash uchun ko'proq kod talab qiladi, lekin test qilish qobiliyatini sezilarli darajada yaxshilaydi.

MVC vs MVP — MVP'da (Model-View-Presenter) Presenter interfeys orqali View'ni oladigan test qilinadigan qatlamdir. MVC'dan farqli o'laroq, Controller UIKit orqali to'g'ridan-to'g'ri View'ni boshqaradi, Presenter freymvorkka bog'liq emas — ViewInterface abstraksiyasi orqali ishlaydi. MVP Jetpack paydo bo'lgunga qadar Android rivojlanishida mashhur edi va eski loyihalarda qo'llaniladi. Presenter Activity'dan uzoqroq yashaydi va ekran aylantirilganda holatni saqlaydi.

MVC vs Clean Architecture — Clean Architecture Use Cases (Interactors), Entities, Gateways va Repository qatlamlarini qo'shadi. MVC Presentation qatlamida qoladi, lekin biznes mantiqi Domain qatlamiga Use Cases bilan chiqariladi. Clean Architecture Massive View Controller muammosini tubdan hal qiladi — Controller faqat Use Cases chaqiruvlari va View'ni yangilashni o'z ichiga oladi. Kamchilik — sinflar va fayllar sonining sezilarli oshishi, bu 50+ ekranli loyihalar uchun asoslanadi.

// iOS'da MVC: Controller hamma narsani o'z ichiga oladi
class OrderViewController: UIViewController {
    func placeOrder() {
        // Validatsiya + tarmoq + UI yangilash
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: mantiq ViewModel'da
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* biznes-mantiq */ }
}

Arxitektura tanlovi jamoa hajmi, loyiha va talab qilinadigan test qilish qobiliyatiga bog'liq. 1–2 dasturchidan iborat jamoa va 20 ekrangacha loyiha uchun MVVM mos keladi. 5 dasturchidan iborat katta jamoa va 50 ekrandan loyiha uchun — modulli tuzilma bilan Clean Architecture. MVC dolzarb bo'lib qolmoqda arxitekturalar evolyutsiyasini tushunish, legacy loyihalarni qo'llab-quvvatlash va murakkab biznes mantiqisiz UIKit'dagi oddiy ekranlar uchun.