הגדרת ארכיטקטורת MVVM ל-iOS: Combine לעומת @Observable

הגדרת ארכיטקטורת MVVM ל-iOS: Combine לעומת @Observable

לעתים קרובות אנו נתקלים בפרויקטים הבנויים על MVC שבהם ה-App Store Review Guidelines תופח לאלפי שורות: בקשות רשת, עיבוד נתונים, עדכוני ממשק משתמש—הכל בקובץ אחד. ארכיטקטורה כזו מסבכת את הבדיקות והתחזוקה. מעבר ל-MVVM פותר בעיות אלה: ה-ObservableObject מקבל על עצמו את הלוגיקה העסקית, וה-View נשאר "טיפש." עם זאת, הגדרת MVVM ב-iOS אינה תבנית אוניברסלית: הבחירה בין Combine, @Observable ו-RxSwift משפיעה על ביצועים ותאימות. הניסיון שלנו מראה כי יישום שנבחר כראוי מקצר את זמן יישום פונקציונליות חדשה ב-40% ומפחית באגי רגרסיה פי 3 הודות לבידוד הלוגיקה. אנו מבטיחים ארכיטקטורה יציבה העומדת ב-@Published.

באיזה יישום MVVM לבחור לפרויקט שלך?

MVVM עם Combine (iOS 13+)

יישום קלאסי עם final class ProfileViewModel: ObservableObject { @Published var user: User? @Published var isLoading = false @Published var error: AppError? private let userRepository: UserRepository private var cancellables = Set<AnyCancellable>() init(userRepository: UserRepository) { self.userRepository = userRepository } func loadProfile() { isLoading = true userRepository.fetchCurrentUser() .receive(on: DispatchQueue.main) .sink( receiveCompletion: { [weak self] completion in self?.isLoading = false if case .failure(let error) = completion { self?.error = error } }, receiveValue: { [weak self] user in self?.user = user } ) .store(in: &cancellables) } } ו-cancellables:

final class ProfileViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false
    @Published var error: AppError?
    private let userRepository: UserRepository
    private var cancellables = Set<AnyCancellable>()

    init(userRepository: UserRepository) {
        self.userRepository = userRepository
    }

    func loadProfile() {
        isLoading = true
        userRepository.fetchCurrentUser()
            .receive(on: DispatchQueue.main)
            .sink(
                receiveCompletion: { [weak self] completion in
                    self?.isLoading = false
                    if case .failure(let error) = completion {
                        self?.error = error
                    }
                },
                receiveValue: { [weak self] user in
                    self?.user = user
                }
            )
            .store(in: &cancellables)
    }
}

נקודות חולשה: יש לאחסן [weak self] במפורש (אחרת המנוי מבוטל מיד), דליפות זיכרון דרך deinit בקלוז'רים—גורם קריסה אופייני בעת ניווט חזרה. אנו מגדירים @Observable עם רישום (logging) לאימות מחזור חיים בדיבאג.

MVVM עם @Observable (iOS 17+)

ה-Observation מקרו מ-@Observable final class ProfileViewModel { var user: User? var isLoading = false var error: AppError? private let userRepository: UserRepository init(userRepository: UserRepository) { self.userRepository = userRepository } func loadProfile() async { isLoading = true defer { isLoading = false } do { user = try await userRepository.fetchCurrentUser() } catch { self.error = error as? AppError } } } framework מסיר קוד תבניתי:

@Observable final class ProfileViewModel {
    var user: User?
    var isLoading = false
    var error: AppError?
    private let userRepository: UserRepository

    init(userRepository: UserRepository) {
        self.userRepository = userRepository
    }

    func loadProfile() async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userRepository.fetchCurrentUser()
        } catch {
            self.error = error as? AppError
        }
    }
}

SwiftUI עוקב אוטומטית אחר תלויות—מבצע רינדור מחדש רק כאשר מאפיינים בשימוש משתנים. אין @Published, אין cancellables. חיסרון: iOS 17+ בלבד, מה שמגביל שימוש בפרויקטים עם קהל רחב.

השוואה בין Combine ו-@Observable

מדוע הזרקת תלויות (Dependency Injection) חשובה?

ללא DI, ViewModel יוצר תלויות בתוך עצמו—בדיקות הופכות לבלתי אפשריות. שימוש במיכל DI מאפשר להחליף שירותים אמיתיים במוקים (mocks) בכמה שורות קוד. לדוגמה, בבדיקות אנו מעבירים MockUserRepository, שמחזיר נתונים מוכנים במקום לפנות לרשת. זה מקצר את זמן ביצוע הבדיקות מ-10 שניות ל-0.1 שניות לבדיקה.

הנה השוואה של מסגרות DI פופולריות:

הבחירה תלויה בגרסת השפה ובדרישות הבדיקות. אנו ממליצים על SwiftDependencies לפרויקטים חדשים על iOS 17+ בשל טיפוסיות חזקה ותמיכה מובנית בבדיקות.

כיצד ליישם MVVM ללא כאבים: מדריך שלב אחר שלב?

1. נתח את מבנה הפרויקט הנוכחי וזהה מודולים.
2. בחר את היישום המתאים: Combine ל-iOS 13+, @Observable ל-iOS 17+, RxSwift אם קיים קוד legacy.
3. צור פרוטוקולים בסיסיים עבור ViewModel ו-Coordinator.
4. הגדר מיכל DI (Swinject, Resolver או SwiftDependencies).
5. בצע ריפקטורינג למסך אחד מ-MVC ל-MVVM כדי להדגים לצוות.
6. כתוב בדיקות יחידה עבור ה-func testLoadProfile_success() async { let mockRepository = MockUserRepository(result: .success(User.fixture)) let sut = ProfileViewModel(userRepository: mockRepository) await sut.loadProfile() XCTAssertEqual(sut.user?.id, User.fixture.id) XCTAssertFalse(sut.isLoading) XCTAssertNil(sut.error) } החדש באמצעות מאגרי mock.
7. תעד את הארכיטקטורה ובצע סקירת קוד.

תהליך זה אורך 2 עד 5 ימים לפרויקט חדש. הגירה מ-MVC legacy ל-MVVM מוערכת באופן פרטנית—צור קשר להערכה.

כיצד לבדוק ViewModel עם async/await?

הודות ל-XCTestExpectation, הבדיקות הופכות ליניאריות. דוגמה:

func testLoadProfile_success() async {
    let mockRepository = MockUserRepository(result: .success(User.fixture))
    let sut = ProfileViewModel(userRepository: mockRepository)
    await sut.loadProfile()
    XCTAssertEqual(sut.user?.id, User.fixture.id)
    XCTAssertFalse(sut.isLoading)
    XCTAssertNil(sut.error)
}

אין צורך ב-async/await עם async—באמצעות protocol ProfileCoordinator: AnyObject { func showEditProfile(user: User) func showSettings() } final class ProfileViewModel { weak var coordinator: ProfileCoordinator? // ... func editProfileTapped() { guard let user else { return } coordinator?.showEditProfile(user: user) } } , בדיקות ViewModel נכתבות באופן ליניארי ונקראות כמו קוד רגיל.

תבנית Coordinator + MVVM

MVVM טהור אינו מטפל בניווט. ה-ViewModel לא צריך לדעת על מסכים. Coordinator עוטף את לוגיקת הניווט:

protocol ProfileCoordinator: AnyObject {
    func showEditProfile(user: User)
    func showSettings()
}

final class ProfileViewModel {
    weak var coordinator: ProfileCoordinator?
    // ...
    func editProfileTapped() {
        guard let user else { return }
        coordinator?.showEditProfile(user: user)
    }
}