הקמת ארכיטקטורת MVP ל-iOS: תבנית ופרקטיקה

הקמת ארכיטקטורת MVP ל-iOS: תבנית ופרקטיקה

תארו לעצמכם: קוד ה-UIKit שלכם גדל ל-20+ מסכים, כל ViewController נושא 500+ שורות, ובדיקות או שאינן קיימות או שדורשות הפעלת סימולטור. ניסיתם MVVM, אבל כריכות ה-Combine עם @Published לא התאימו—הפרויקט ישן מדי, או שהצוות שלכם הגיע מאנדרואיד עם תרבות ה-MVP שלו. הצוות שלנו הקים MVP על 15+ פרויקטים ומבטיח שהתבנית עובדת מהקומיט הראשון. במאמר זה, נסקור פרוטוקולים מרכזיים, בידוד UIKit, ובדיקות ללא סימולטור.

ויקיפדיה: Model-View-Presenter הוא תבנית ארכיטקטונית שבה ה-Presenter משמש כמתווך בין View ל-Model. ב-iOS, זה שימושי במיוחד לפרויקטי UIKit גדולים שבהם MVVM עם Combine ידרוש שכתוב הקוד לסטאק ריאקטיבי.

למה MVP מתאים לפרויקטי UIKit

אם הפרויקט שלכם אינו רשימה פשוטה עם פרטים אלא אפליקציית UIKit מורכבת עם מסכים מרובים, MVP מספק הפרדה ברורה: ה-Presenter לא רואה UIKit, ה-ViewController דק יותר, ובדיקות נכתבות ללא סימולטור. בניגוד ל-MVVM שבו ה-ViewModel נרשם ל-Combine, MVP משתמש בפרוטוקולים פשוטים והפניות חלשות. זה מוריד את חף הכניסה ואינו דורש שכתוב הקוד לסטאק ריאקטיבי. גישה כזו היא אלמנט של ארכיטקטורה נקייה ל-iOS, שכן תלויות מצביעות משכבות חיצוניות לליבה.

מה זה MVP ב-iOS וכיצד הוא שונה מ-MVVM

לפי ההגדרה Model-View-Presenter הוא תבנית ארכיטקטונית שבה ה-Presenter משמש כמתווך בין View ל-Model. ב-MVVM, ה-ViewController נרשם למאפייני @Published של ה-ViewModel דרך Combine. ב-MVP, ה-Presenter לא יודע דבר על UIKit: הוא מתקשר עם פרוטוקול View שמיושם על ידי ה-ViewController. אין כריכות, אין ריאקטיביות—שליטה מלאה על זרימת הנתונים.

// View protocol — интерфейс для Presenter
protocol ProfileView: AnyObject {
    func showUser(_ user: User)
    func showLoading(_ isLoading: Bool)
    func showError(_ message: String)
}

// Presenter — чистый Swift, ноль UIKit
final class ProfilePresenter {
    weak var view: ProfileView?
    private let userRepository: UserRepository

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

    func viewDidLoad() {
        view?.showLoading(true)
        Task {
            do {
                let user = try await userRepository.fetchCurrentUser()
                await MainActor.run {
                    view?.showLoading(false)
                    view?.showUser(user)
                }
            } catch {
                await MainActor.run {
                    view?.showLoading(false)
                    view?.showError(error.localizedDescription)
                }
            }
        }
    }
}

// ViewController — тонкий, только UI
final class ProfileViewController: UIViewController, ProfileView {
    private var presenter: ProfilePresenter!

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

    func showUser(_ user: User) {
        nameLabel.text = user.name
        avatarImageView.load(url: user.avatarURL)
    }

    func showLoading(_ isLoading: Bool) {
        isLoading ? activityIndicator.startAnimating() : activityIndicator.stopAnimating()
    }

    func showError(_ message: String) {
        // Toast или Alert
    }
}

נקודה מרכזית: // View protocol — интерфейс для Presenter protocol ProfileView: AnyObject { func showUser(_ user: User) func showLoading(_ isLoading: Bool) func showError(_ message: String) } // Presenter — чистый Swift, ноль UIKit final class ProfilePresenter { weak var view: ProfileView? private let userRepository: UserRepository init(userRepository: UserRepository) { self.userRepository = userRepository } func viewDidLoad() { view?.showLoading(true) Task { do { let user = try await userRepository.fetchCurrentUser() await MainActor.run { view?.showLoading(false) view?.showUser(user) } } catch { await MainActor.run { view?.showLoading(false) view?.showError(error.localizedDescription) } } } } } // ViewController — тонкий, только UI final class ProfileViewController: UIViewController, ProfileView { private var presenter: ProfilePresenter! override func viewDidLoad() { super.viewDidLoad() presenter.viewDidLoad() } func showUser(_ user: User) { nameLabel.text = user.name avatarImageView.load(url: user.avatarURL) } func showLoading(_ isLoading: Bool) { isLoading ? activityIndicator.startAnimating() : activityIndicator.stopAnimating() } func showError(_ message: String) { // Toast или Alert } } —הפניה חלשה היא חובה, אחרת מקבלים מעגל שמירה (retain cycle). ה-Presenter מחזיק את ה-View, ה-View מחזיק את ה-Presenter; אחד מהם חייב להיות weak var view: ProfileView?.

איך לבדוק Presenter ללא סימולטור

היתרון המרכזי של MVP: ה-Presenter ניתן לבדיקה ללא סימולטור. הנה דוגמה עם מוק (mock):

final class MockProfileView: ProfileView {
    var didShowUser = false
    var isLoading = false

    func showUser(_ user: User) {
        didShowUser = true
    }

    func showLoading(_ isOn: Bool) {
        isLoading = isOn
    }

    func showError(_ message: String) {
        /* ignore */
    }
}

func testViewDidLoad_success() async {
    let mockView = MockProfileView()
    let mockRepository = MockUserRepository(result: .success(User.fixture))
    let sut = ProfilePresenter(userRepository: mockRepository)
    sut.view = mockView
    sut.viewDidLoad()

    // Небольшая пауза для async Task
    try await Task.sleep(nanoseconds: 100_000_000)

    XCTAssertTrue(mockView.didShowUser)
    XCTAssertFalse(mockView.isLoading)
}

הבדיקה אורכת מילישניות, אין צורך ב-XCUITest. כיסוי קוד עם בדיקות כאלה מגיע ל-80%, וחיסכון בתקציב רגרסיה עד 40%. השוו: ViewModel טיפוסי של MVVM עם Combine דורש הגדרת weak או final class MockProfileView: ProfileView { var didShowUser = false var isLoading = false func showUser(_ user: User) { didShowUser = true } func showLoading(_ isOn: Bool) { isLoading = isOn } func showError(_ message: String) { /* ignore */ } } func testViewDidLoad_success() async { let mockView = MockProfileView() let mockRepository = MockUserRepository(result: .success(User.fixture)) let sut = ProfilePresenter(userRepository: mockRepository) sut.view = mockView sut.viewDidLoad() // Небольшая пауза для async Task try await Task.sleep(nanoseconds: 100_000_000) XCTAssertTrue(mockView.didShowUser) XCTAssertFalse(mockView.isLoading) } —MVP פשוט ומהיר משמעותית כאן.

מה כלול בהקמת MVP

כאשר אתם מזמינים הקמת MVP, אתם מקבלים:

• קבצי Swift מלאים למודול: Presenter, ViewController, Router.
• בדיקות יחידה ל-Presenter (5–10 מקרים למודול, 80% כיסוי).
• הוראות אינטגרציה להוספת מסכים חדשים.
• הדרכת צוות (1–2 שיחות עם הדגמה).

העבודה אורכת 2–3 ימים לפרויקט חדש. צרו קשר כדי להעריך את היקף ההמרה של מסכים קיימים. קבלו ייעוץ על יישום MVP בפרויקט שלכם.

ניווט ב-MVP: מה זה Router / Wireframe?

ה-Presenter לא צריך לנהל ניווט ישירות—זה מפר את עקרון האחריות היחידה. הפתרון הקלאסי הוא Router (או XCTestExpectation במונחי MVP המקוריים):

protocol ProfileRouter: AnyObject { func navigateToEditProfile(user: User) func navigateToSettings() } 

Sink קונקרטי עובד עם Wireframe—התלות ב-UIKit מבודדת. ה-Presenter מקבל את ה-Router דרך DI וקורא ל-protocol ProfileRouter: AnyObject { func navigateToEditProfile(user: User) func navigateToSettings() } מבלי לדעת מה קורה מתחת למכסה המנוע.

איך להמיר מ-MVC ל-MVP

המרת מסך MVC קיים ל-MVP היא משימה של 4–8 שעות למסך. צרו פרוטוקול View, חלצו לוגיקה ל-Presenter, הוסיפו Router. העבירו תלויות Model ל-Presenter. יישמו את ה-View ב-ViewController. בדקו את ה-Presenter. תוכנית זו צעד-אחר-צעד חלה על כל מסך, והארכיטקטורה הסופית הופכת למודולרית וניתנת לבדיקה.

הקמת MVP צעד-אחר-צעד לפרויקט חדש

1. הגדירו מודולים. כל מסך הוא מודול נפרד עם פרוטוקולי View, Presenter, Router.
2. כתבו פרוטוקולים. View—רק שיטות תצוגה; Presenter—שיטות מחזור חיים וטיפול באירועים; Router—שיטות ניווט.
3. יישמו את ה-Presenter. כל הלוגיקה, עבודת שרת/DB. ללא UIKit.
4. יישמו את ה-View (ViewController). העבירו קריאות ל-Presenter.
5. יישמו את ה-Router. צרו מחלקה שמשתמשת ב-UINavigationController למעברים.
6. הגדירו DI. השתמשו במפעל מודולים או Swinject להרכבת תלויות.
7. כתבו בדיקות. כסו כל שיטת Presenter (5–10 מקרים למודול).

השוואת MVP מול MVVM

טעויות נפוצות ביישום MVP

• שכחת ProfileRouterImpl על view—מעגל שמירה, דליפת זיכרון. תמיד השתמשו ב-UINavigationController.
• ערבוב לוגיקת ניווט ב-Presenter—חלצו Router.
• אי בדיקת ה-Presenter—אתם מאבדים את היתרון המרכזי של MVP. כסו עם מוקים.
• סיבוך יתר של פרוטוקולים—שיטה אחת למסך במקום קיבוץ. שמרו על מספר סביר של שיטות View (5–7).

הזמינו הקמת MVP לפרויקט שלכם—קבלו תבנית מוכנה תוך 2–3 ימים. אנו מבטיחים שלפרויקט שלכם תהיה מבנה ניתן לבדיקה, והצוות שלכם יקבל זרימת עבודה ללא תקורה מיותרת. צרו קשר לייעוץ.