10. Taqqoslash & Tanlov: Qaysi birini qachon ishlatish kerak?

Arxitektura

iOS Arxitektura 10: Yakuniy Qo'llanma — Qaysi Arxitekturani Qachon Tanlash? Real Loyihalar Tahlili

Holat: 2026-yil oktabr. Ushbu yakuniy darsda iOS olamidagi barcha asosiy arxitektura pattern'larini taqqoslaymiz, qaysi birini qachon ishlatishni ko'rib chiqamiz va real kompaniyalar tajribasi hamda intervyu savollarini tahlil qilamiz.

Mundarija

1. Barcha arxitekturalar bir joyda
2. Loyiha hajmiga qarab tanlash
3. Kompaniyalarda qaysi pattern ishlatiladi?
4. Real Interview Savollari (Top 10)
5. Anti-Patterns (Nima qilmaslik kerak)
6. Amaliy mashq: Bitta app'ni 3 xil arxitekturada ko'rish
7. Arxitektura tanlash Decision Tree
8. Xulosa
9. Manbalar

1. Barcha arxitekturalar bir joyda {#barcha-arxitekturalar}

Yaqin darslar davomida biz MVC, MVVM, MVP, VIPER, Clean Architecture, TCA va MVI kabi ko'plab pattern'larni ko'rib chiqdik. Endi barchasini bitta taqqoslash jadvalida jamlaymiz.

iOS Arxitektura Patternlarining Qiyosiy Matritsasi

Senior eslatmasi: Hech qaysi pattern "eng zo'r" emas. Har birining o'z o'rni va vazifasi bor. Mukammal arxitektura yo'q, faqat loyiha talablariga mos keladigan to'g'ri tanlov bor.

2. Loyiha hajmiga qarab tanlash {#loyiha-hajmi}

Siz qaysi pattern'ni tanlashingiz ko'p hollarda jamoangiz va loyihangiz qanchalik katta ekanligiga bog'liq:

• Kichik loyihalar (1-3 ekran, 1 dasturchi):
• Tavsiya: MVC yoki oddiy MVVM.
• Sababi: Tezkorlik muhim. Kichik app uchun VIPER yoki Clean Architecture yozish — chivin o'ldirish uchun to'pdan o't ochish bilan barobar (Over-engineering).
• O'rta loyihalar (5-15 ekran, 2-5 dasturchi):
• Tavsiya: MVVM + Coordinator yoki MVP.
• Sababi: Bu hajmda navigatsiya mantiqlarini ajratish (Coordinator) va test yozish zarurati paydo bo'ladi.
• Katta loyihalar (20+ ekran, 5+ dasturchi):
• Tavsiya: Clean Architecture + MVVM, yoki VIPER. Modulli arxitektura (SPM/Tuist) bilan birga.
• Sababi: Ko'p dasturchilar bir vaqtda ishlashi uchun aniq chegaralar va "Contract"lar (protokollar) kerak. Kodning testlanishi juda muhim.
• SwiftUI-first loyihalar:
• Tavsiya: TCA (The Composable Architecture) yoki zamonaviy @Observable MVVM.
• Sababi: SwiftUI state-driven (holatga asoslangan) freymvork. TCA va zamonaviy MVVM bunga juda mos.
• Real-time / Chat / FinTech loyihalar:
• Tavsiya: MVI/Redux yoki TCA.
• Sababi: Bitta yagona State (Single Source of Truth) ma'lumotlar xato ko'rsatilishining oldini oladi (masalan, akkaunt balansi).

3. Kompaniyalarda qaysi pattern ishlatiladi? {#kompaniyalar}

Dunyo miqyosidagi top kompaniyalar qaysi yondashuvlardan foydalanishiga qarab ko'p narsani o'rganish mumkin:

4. Real Interview Savollari (Top 10) {#intervyu-savollari}

Arxitektura haqidagi suhbatlarda eng ko'p tushadigan savollar va ularga qanday professional javob berish kerakligi:

1. "MVC va MVVM farqi nima?"
2. Javob: "MVC'da ViewController hamma narsani (View, Model, Network, Routing) boshqaradi. MVVM'da esa UI va Biznes logika ajratiladi: ViewModel ma'lumotlarni View tushunadigan shaklga keltiradi, ViewController faqat View'ni ko'rsatadi va binding qiladi. Natijada MVVM testable (testlash osonroq) bo'ladi."
3. "MVVM'da ViewModel UIKit'ni import qilishi kerakmi?"
4. Javob: "Yo'q! Aslo. ViewModel faqat Foundation (va ehtimol Combine/Observation) import qilishi kerak. Agar ViewModel'ga UIImage yoki UIColor kiritayotgan bo'lsangiz, demak arxitekturani buzyapsiz. ViewModel ma'lumotni String yoki Enum ko'rinishida berishi, View o'zi rang yoki rasmga aylantirishi kerak."
5. "VIPER'da Router (Wireframe) nima qiladi?"
6. Javob: "Router navigatsiya logikasini boshqaradi. Ekrandan ekranga o'tish (push, present), Dependency Injection orqali modulning barcha komponentlarini (View, Interactor, Presenter) yaratish va bir-biriga ulash vazifasini bajaradi."
7. "Clean Architecture'da Dependency Rule nima?"
8. Javob: "Kod qaramliklari (dependencies) faqat tashqaridan ichkariga (tashqi qatlamdan ichki qatlamga) qarab yo'nalgan bo'lishi kerak. Ya'ni, UI yoki Database qatlami (tashqi) Entity va UseCase'larni (ichki) bilishi mumkin, lekin Entity yoki UseCase tashqi qatlamlar haqida hech narsa bilmasligi kerak."
9. "TCA'da Reducer nima vazifa bajaradi?"
10. Javob: "Reducer ilovaning joriy holati (State) va yuz bergan voqea (Action) ni qabul qilib, ularni tahlil qiladi va yangi Holat (State) yaratadi hamda kerak bo'lsa, yon-ta'sir (Effect) qaytaradi. Barcha logika faqat Reducer'da yoziladi."
11. "Qaysi pattern'da test yozish eng oson?"
12. Javob: "Clean Architecture + VIPER/MVVM yoki TCA. Chunki bu pattern'larda biznes-logika UI (View/ViewController)dan to'liq ajratilgan va protokollar orqali bog'langan bo'ladi, bu esa Mock obyektlar yaratishni juda osonlashtiradi."
13. "Yangi loyiha boshlayotganda qaysi pattern tanlaysiz va nega?"
14. Javob: "Bu loyihaning talablariga bog'liq. Agar tezda MVP (Minimum Viable Product) chiqarish kerak bo'lsa MVVM ishlataman. Agar loyiha kelajakda kattalashishi aniq bo'lsa va jamoada ko'p dasturchi bo'lsa, Clean Architecture bilan MVVM yoki VIPER tanlayman. Agar loyiha to'liq SwiftUI'da bo'lsa, TCA yoki zamonaviy @Observable MVVM yaxshi yechim."
15. "SOLID prinsiplarini tushuntiring."
16. Javob: "S (Single Responsibility) - klass faqat bitta narsaga javobgar bo'lishi kerak. O (Open/Closed) - kengaytirish uchun ochiq, o'zgartirish uchun yopiq. L (Liskov Substitution) - subklass o'z superklassi o'rnida ishlay olishi kerak. I (Interface Segregation) - bitta katta protokol o'rniga kichik-kichik protokollar bo'lishi kerak. D (Dependency Inversion) - yuqori qatlam quyi qatlamga qaram bo'lmasligi, ikkisi ham abstraksiyaga qaram bo'lishi kerak."
17. "Dependency Injection (DI) nima?"
18. Javob: "Obyekt o'ziga kerak bo'lgan qaramliklarni (dependency) o'zi yaratmasdan, ularni tashqaridan (initializer, property yoki method orqali) qabul qilishidir. Bu kodni test qilishni osonlashtiradi, chunki haqiqiy qaramlik o'rniga mock/fake obyekti berib yuborish mumkin."
19. "Massive View Controller (MVC) muammosi nimada?"
20. Javob: "View va ViewController ajratilmaganligi sababli, ViewController'ga tarmoq so'rovlari, ma'lumotni o'zgartirish, tableview delegatlari, navigatsiya aralashib ketadi. Natijada kod o'qilishi qiyinlashadi, test yozib bo'lmaydi va xatolar ehtimoli ortadi."

5. Anti-Patterns (Nima qilmaslik kerak) {#anti-patterns}

Arxitektura quramiz deb, noto'g'ri yondashuvlarga kirib qolish oson. Quyidagi Anti-Pattern'lardan qoching:

• "Massive ViewModel" (MVVM): MVC'dan qochib, barcha mantiqni ViewModel'ga tiqib yuborish. ViewModel 1000+ qatordan oshib ketadimi? Demak, sizda UseCase/Interactor yoki Manager'lar yetishmayapti.
• "God Object": Loyihada bitta shunday klass (masalan, AppManager yoki DataStore) borki, unda hamma narsa mujassam. Bu SOLIDning Single Responsibility prinsipini buzadi.
• "Spaghetti Navigation": ViewController'lar bir-birini to'g'ridan-to'g'ri chaqirishi. Bu kodning qayta ishlatilishini nolga tushiradi. (Yechim: Coordinator yoki Router ishlating).
• "Leaky Abstraction": Pastki qatlam sirlarining yuqoriga chiqib ketishi. Masalan, Repository'dan to'g'ridan-to'g'ri CoreData obyekti (NSManagedObject) qaytarish va uni ViewModel'da ishlatish. U yerda aniq DTO yoki Domain Model qaytishi kerak.
• "Over-Engineering": Oddiy qilinadigan narsani murakkablashtirish. 2 ta ekrani bor ob-havo dasturi uchun Clean Architecture + VIPER + RxSwift qilib yozish - bu Over-engineering!

6. Amaliy mashq: Bitta app'ni 3 xil arxitekturada ko'rish {#amaliy-mashq}

Keling, oddiygina "Notes" (Eslatmalar) ilovasidagi Eslatma yaratish (Add Note) funksiyasini turli arxitekturalarda qanday ko'rinishini taqqoslaymiz.

A) MVC Versiyasi (Qisqa va sodda, lekin hamma narsa aralash)

import UIKit

// Bitta joyda hamma narsa: UI, Network/Storage logikasi
class AddNoteViewControllerMVC: UIViewController {
    let textField = UITextField()
    let saveButton = UIButton()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // ... UI setup
        saveButton.addTarget(self, action: #selector(saveTapped), for: .touchUpInside)
    }
    
    @objc func saveTapped() {
        guard let text = textField.text, !text.isEmpty else { return }
        
        // Data base bilan ishlash to'g'ridan-to'g'ri shu yerda! (BAD practice)
        let newNote = Note(id: UUID().uuidString, text: text)
        Database.shared.save(newNote)
        
        // Navigatsiya ham shu yerda
        self.navigationController?.popViewController(animated: true)
    }
}

B) MVVM Versiyasi (O'rtacha, UI va Logika ajratilgan)

import SwiftUI

// 1. Model
struct Note: Identifiable {
    let id: String
    let text: String
}

// 2. ViewModel - faqat Logika
@MainActor
@Observable
class AddNoteViewModel {
    var text: String = ""
    var isSaved: Bool = false
    
    private let database: DatabaseProtocol // Dependency Injection
    
    init(database: DatabaseProtocol = Database.shared) {
        self.database = database
    }
    
    func saveNote() {
        guard !text.isEmpty else { return }
        let note = Note(id: UUID().uuidString, text: text)
        database.save(note)
        isSaved = true
    }
}

// 3. View - Faqat UI va Binding
struct AddNoteViewMVVM: View {
    @State private var viewModel = AddNoteViewModel()
    @Environment(\.dismiss) var dismiss
    
    var body: some View {
        VStack {
            TextField("Enter note...", text: $viewModel.text)
            
            Button("Save") {
                viewModel.saveNote()
            }
        }
        .onChange(of: viewModel.isSaved) { _, saved in
            if saved { dismiss() } // Navigatsiyani View/Coordinator hal qiladi
        }
    }
}

C) VIPER Versiyasi (Uzun, ammo to'liq izolyatsiya qilingan va testbop)

import UIKit

// 1. Entity
struct NoteEntity { let id: String; let text: String }

// 2. View (Protocol)
protocol AddNoteViewProtocol: AnyObject {
    func showError()
}

// 3. Interactor (Protocol + Implementation - Biznes logika)
protocol AddNoteInteractorProtocol {
    func saveNote(text: String)
}

class AddNoteInteractor: AddNoteInteractorProtocol {
    weak var presenter: AddNotePresenterProtocol?
    let database: DatabaseProtocol
    
    init(database: DatabaseProtocol) { self.database = database }
    
    func saveNote(text: String) {
        if text.isEmpty {
            presenter?.didFailToSave()
        } else {
            let note = NoteEntity(id: UUID().uuidString, text: text)
            database.save(note)
            presenter?.didSaveSuccessfully()
        }
    }
}

// 4. Presenter (UI'ni boshqaradi va Interactor bilan gaplashadi)
protocol AddNotePresenterProtocol: AnyObject {
    func didTapSave(text: String)
    func didSaveSuccessfully()
    func didFailToSave()
}

class AddNotePresenter: AddNotePresenterProtocol {
    weak var view: AddNoteViewProtocol?
    var interactor: AddNoteInteractorProtocol?
    var router: AddNoteRouterProtocol?
    
    func didTapSave(text: String) { interactor?.saveNote(text: text) }
    func didSaveSuccessfully() { router?.navigateBack() }
    func didFailToSave() { view?.showError() }
}

// 5. Router (Navigatsiya)
protocol AddNoteRouterProtocol { func navigateBack() }

class AddNoteRouter: AddNoteRouterProtocol {
    weak var viewController: UIViewController?
    func navigateBack() { viewController?.navigationController?.popViewController(animated: true) }
}

// 6. View (Implementation)
class AddNoteViewControllerVIPER: UIViewController, AddNoteViewProtocol {
    var presenter: AddNotePresenterProtocol?
    // UI elements...
    
    @objc func saveTapped() {
        presenter?.didTapSave(text: "some text")
    }
    
    func showError() { print("Error UI") }
}

VIPER'ning birgina amal uchun qanchalik ko'p kod talab qilishi shu yerdan ham ma'lum.

7. Arxitektura tanlash Decision Tree {#decision-tree}

Qaysi arxitekturani tanlashni bilmayapsizmi? Quyidagi "Qaror qabul qilish daraxti" (Decision Tree) sizga yordam beradi:

iOS Arxitekturasini Tanlash: Qarorlar Daraxti (Decision Tree)

Qaror qabul qilishda quyidagi 5 asosiy savolga javob berishingiz kifoya:

1. Loyiha kichik va muddat o'ta qisqami? (Hackathon, prototip, 1-3 ekran, 1 dasturchi)
2. Ha: MVC yoki oddiy MVVM. Tezlik muhim, ortiqcha kod yozish qimmatli vaqtni o'g'irlaydi.
3. Yo'q: Keyingi savolga o'ting.
4. Ilova asosan SwiftUI-first (State-driven)mi?
5. Ha (Kompleks holat va qat'iy test zarurati): TCA (The Composable Architecture). Single state store, time-travel debugging va deterministik testlar.
6. Ha (Standart va yengil): Modern MVVM (@Observable + SwiftData). Apple standartlariga 100% mos va ortiqcha kutubxonasiz.
7. Yo'q (UIKit yoki gibrid): 3-savolga o'ting.
8. Katta jamoa (5+ dev) va 20+ ekran mavjudmi?
9. Yo'q (2-5 dev, 5-20 ekran): MVVM + Coordinator. O'rta hajmdagi ilovalar uchun oltin o'rtaliq. Ekranlar orasidagi navigatsiya toza va testlash oson.
10. Ha: 4-savolga o'ting.
11. 100% Test coverage va qat'iy korporativ qatlamlar shartmi?
12. Ha: Clean Architecture (VIPER yoki MVVM bilan). Banklar, FinTech va yirik enterprise tizimlar uchun standart. Domain, Data va Presentation qatlamlari mustaqil ajraladi.
13. Yo'q: 5-savolga o'ting.
14. Real-time, FinTech balans yoki Chat oqimlari ustuvormi?
15. Ha: MVI / Redux (Unidirectional Data Flow). Bitta yagona State daraxti (Single Source of Truth) race-condition va noaniq holat o'zgarishlarining oldini oladi.

Xulosa {#xulosa}

Muhim: Arxitektura — bu maqsadsiz yozilgan qoidalar to'plami emas. U — to'g'ri ish uchun tanlangan to'g'ri asbob.

• Hech qaysi pattern mukammal emas, hammasining ijobiy va salbiy (trade-off) tomonlari bor.
• Yaxshi Senior Dasturchi "Men doim MVVM ishlataman" demaydi, balki "Bu muammoni yechish uchun mana bu pattern mos keladi" deydi.
• Arxitekturaning asl maqsadi — kodni tushunarli qilish, test yozishga imkon yaratish, jamoaviy ishlashni osonlashtirish va kelajakdagi o'zgarishlarga (yangilanishlarga) tayyor turish.
• Pattern'larni yodlashni emas, ular yechayotgan MUAMMONI tushunishni o'rganing!

Ushbu "iOS Arxitektura" kursi davomida o'rgangan bilimlariz sizni nafaqat kod yozuvchi (coder), balki tizim yaratuvchi (architect) darajasiga ko'tarishiga ishonamiz.

Manbalar {#manbalar}

1. "Clean Architecture: A Craftsman's Guide to Software Structure and Design" — Robert C. Martin (Uncle Bob).
2. "iOS App Architecture" — objc.io.
3. "Advanced iOS App Architecture" — Ray Wenderlich (hozirgi Kodeco).
4. Apple rasmiy hujjatlari va WWDC videolari (SwiftUI Data Flow, Observation Framework).
5. GitHub'dagi turli ochiq kodli loyihalar (TCA repositoriyasi va hk).