MVP — що це таке, патерн Model-View-Presenter в iOS та Android

Що таке MVP: суть патерну Model-View-Presenter

MVP (Model-View-Presenter) — архітектурний патерн, запропонований Мартіном Фаулером на початку 2000-х як еволюція MVC для покращення тестованості користувацького інтерфейсу. Model керує даними та бізнес-логікою, View відповідає за відображення та обробку введення користувача, Presenter — центральний компонент, який отримує події від View, витягує дані з Model та формує стан для відображення.

Головна відмінність MVP від MVC — Presenter не має прямого посилання на View. Натомість Presenter взаємодіє з View через інтерфейс ViewContract. View реалізує цей інтерфейс і передає себе Presenter. Це розриває залежність від UIKit (iOS) або Android Framework — Presenter тестується ізольовано з mock-реалізацією ViewContract. В MVC контролер UIViewController безпосередньо оновлює UILabel, в MVP Presenter викликає view.showName(name), а View вирішує, як відобразити.

Принцип єдиної відповідальності в MVP дотримується суворіше, ніж в MVC: View відповідає лише за рендеринг, Model — за дані, Presenter — за логіку та координацію. У реальних проєктах Presenter займає 40–60% коду екрану, View — 20–30%, Model — 20–30%. Такий розподіл дозволяє тестувати ключову бізнес-логіку без запуску емулятора Android або симулятора iOS.

MVP в Android: Presenter, ViewContract та Activity

MVP в Android використовує Activity або Fragment як View, яка реалізує ViewContract — інтерфейс з методами відображення даних. Presenter створюється в Activity, підписує View на себе та керує завантаженням даних. При повороті екрану Activity перестворюється — Presenter може зберігатися через retain-фрагмент або зовнішнє сховище, що вирішує проблему втрати стану, характерну для чистого MVC.

// ViewContract — інтерфейс для зв'язку Presenter з View
interface UserView {
    fun showLoading()
    fun hideLoading()
    fun showUser(user: User)
    fun showError(message: String)
}

// Presenter — тестований шар логіки
class UserPresenter(
    private val repository: UserRepository
) {
    private var view: UserView? = null

    fun attachView(view: UserView) {
        this.view = view
    }

    fun detachView() {
        view = null
    }

    fun loadUser(userId: Int) {
        view?.showLoading()
        repository.getUser(userId) { result ->
            view?.hideLoading()
            result.onSuccess { user ->
                view?.showUser(user)
            }.onFailure { e ->
                view?.showError(e.message ?: "Unknown error")
            }
        }
    }
}

// View (Activity) реалізує інтерфейс
class UserActivity : AppCompatActivity(), UserView {
    private val presenter = UserPresenter(UserRepository())

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        presenter.attachView(this)
        presenter.loadUser(42)
    }

    override fun onDestroy() {
        presenter.detachView()
        super.onDestroy()
    }

    override fun showUser(user: User) { /* обновить UI */ }
    override fun showLoading() { /* показать ProgressBar */ }
    override fun hideLoading() { /* скрыть ProgressBar */ }
    override fun showError(message: String) { /* показать Snackbar */ }
}

Управління життєвим циклом — ключова проблема MVP на Android. Activity знищується при повороті екрану, і presenter.attachView() викликається заново в onCreate(). Якщо завантаження даних асинхронне (RxJava, корутини), на момент завершення View може бути detached. Рішення — скасування підписок в detachView() або використання Loader з Support Library (для проєктів без Jetpack). В IT Sectr ми роками застосовували зв'язку MVP + RxJava в комерційних проєктах — патерн стабільний, але вимагає дисципліни в управлінні підписками.

Ретейн-фрагменти — механізм збереження Presenter при повороті екрану. Фрагмент без UI (setRetainInstance(true)) живе довше за Activity та зберігає посилання на Presenter. При перестворенні Activity фрагмент передає той самий Presenter новій Activity. Ретейн-фрагменти deprecated з AndroidX, але їх pre-Jetpack аналог (Fragment.setRetainInstance) досі працює в легасі-проєктах. У сучасній розробці Google рекомендує ViewModel замість ретейн-фрагментів.

MVP в iOS: Presenter та View Protocol

MVP в iOS будується через протокол View. UIViewController реалізує протокол, Presenter не імпортує UIKit і чисто тестується. На відміну від Apple MVC, де UIViewController сам містить логіку та прямі IBOutlet-зв'язки, Presenter керує станом і командує View через методи протоколу. View не приймає рішень — вона виконує команди Presenter: showUser, showLoading, navigateToProfile.

import Foundation

// View Protocol — абстракція для Presenter
protocol UserViewProtocol: AnyObject {
    func showLoading()
    func hideLoading()
    func display(user: User)
    func displayError(message: String)
}

// Presenter — чиста логіка, без UIKit
final class UserPresenter {
    private weak var view: UserViewProtocol?
    private let service: UserServiceProtocol

    init(service: UserServiceProtocol) {
        self.service = service
    }

    func attach(view: UserViewProtocol) {
        self.view = view
    }

    func detach() {
        view = nil
    }

    func loadUser(id: Int) {
        view?.showLoading()
        service.fetchUser(id: id) { [weak self] result in
            guard let self else { return }
            self.view?.hideLoading()
            switch result {
            case .success(let user):
                self.view?.display(user: user)
            case .failure(let error):
                self.view?.displayError(message: error.localizedDescription)
            }
        }
    }
}

// View (UIViewController) реалізує протокол
final class UserViewController: UIViewController, UserViewProtocol {
    private let presenter = UserPresenter(service: UserService())

    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.attach(view: self)
        presenter.loadUser(id: 42)
    }

    func display(user: User) {
        nameLabel.text = user.name
    }
    // ... решта методів протоколу
}

Weak reference на View — обов'язкова умова в iOS MVP. UIViewController може бути знищений (pop з navigation stack), а його замикання в Presenter створить retain cycle. Слабке посилання (weak var) гарантує, що View звільняється, коли залишає екран, незалежно від наявності асинхронних операцій в Presenter. В Android аналогічна проблема вирішується через detachView() — виклик в onDestroy() обнуляє посилання на View.

Passive View vs Supervising Controller — два варіанти MVP від Мартіна Фаулера. Passive View: View не містить логіки, Presenter повністю керує станом. Supervising Controller: View сама робить просте прив'язування даних (наприклад, через data binding), Presenter втручається лише в складні сценарії. В мобільній розробці Passive View застосовується частіше — він дає максимальну тестованість та передбачуваність стану екрану.

Відмінності MVP від MVC та переваги тестування

Головна відмінність MVP та MVC — спосіб зв'язку з View. В MVC Controller має пряме посилання на View (UIViewController.IBOutlets, Activity.findViewById). В MVP Presenter взаємодіє з View через інтерфейс ViewContract. Ця відмінність кардинально змінює тестованість: Mock-об'єкт, що реалізує ViewContract, дозволяє перевірити логіку Presenter без запуску застосунку, емулятора та UI-фреймворку.

Приклад юніт-тесту Presenter на Kotlin: створюється mock UserView, передається в Presenter, викликається loadUser, перевіряється, що showUser викликаний з коректними даними. Тест виконується за мілісекунди, не потребує емулятора. На iOS аналогічно — OCMock або протокол-стаб перевіряє виклики методів UserViewProtocol. В проєктах IT Sectr з MVP покриття бізнес-логіки юніт-тестами досягало 85–90%, що в 2–3 рази вище, ніж в аналогічних MVC-проєктах.

Коли MVP доцільніший за MVC — в проєктах з жорсткими вимогами до стабільності: банківські застосунки, медичні системи, платіжні термінали. У цих сферах ціна помилки висока, і юніт-тести критичні. В проєктах Post-MVP (коли продукт вже на ринку, але база коду legacy) MVP дозволяє поступово виносити логіку з Massive View Controller в тестований шар без повного перепису архітектури.

Обмеження MVP та перехід до MVVM

Основні недоліки MVP — зростання кількості інтерфейсів та ручне керування підписками. Кожен екран потребує мінімум один ViewContract + Presenter, для 50 екранів — 50 інтерфейсів та 50 класів Presenter. В MVVM ViewModel замінює Presenter і використовує реактивні механізми (LiveData, StateFlow, ObservableObject), що усуває необхідність в ручному attach/detach та інтерфейсах ViewContract.

RxJava та MVP — популярна комбінація в Android 2015–2019. Presenter підписується на Observable з Repository, відображає результат через ViewContract. Проблема: disposable потрібно явно скасовувати в detachView(), інакше витік підписки спричинить краш при оновленні detached View. Бібліотеки RxLifecycle та AutoDispose частково автоматизували відписку, але додавали залежність. В IT Sectr ми перейшли з MVP+RxJava на MVVM+Flow у 2020 році — код став коротшим на 25–30% за рахунок відмирання ViewContract.

Міграція з MVP на MVVM — поетапний процес. 1) Замінити ViewContract на LiveData/StateFlow в Presenter. 2) Прибрати методи attach/detach — підписка йде через observe(). 3) Перейменувати Presenter на ViewModel. 4) Інтегрувати DI (Hilt/Koin) для ViewModelFactory. Міграція одного екрану займає 2–4 години, всієї бази коду — 2–4 тижні для проєкту на 50–100 екранів. Після міграції ViewContract-інтерфейси видаляються, код скорочується, тести залишаються.

MVP в сучасній розробці — патерн живий, але поступається MVVM та MVI. Google офіційно рекомендує MVVM з Jetpack для нових проєктів. Apple — MVVM зі SwiftUI. Однак знання MVP обов'язкове для роботи з легасі-кодом: сотні Android-застосунків в Google Play досі працюють на MVP, включаючи застосунки великих банків, рітейлерів та транспортних компаній. Розуміння MVP — фундамент для освоєння MVI та Clean Architecture, оскільки Presenter — прямий попередник Use Case в термінах Роберта Мартіна.