В чем разница между Presenter и ViewModel?

Разница между Presenter и ViewModel в архитектуре iOS

В iOS-разработке концепции Presenter (из паттерна MVP) и ViewModel (из MVVM) часто вызывают вопросы, поскольку оба слоя отвечают за бизнес-логику и подготовку данных для отображения. Однако их философия, ответственность и связь с View кардинально различаются.

Ключевые различия в таблице

Подробное сравнение

1. Presenter в MVP (Model-View-Presenter)

Presenter действует как посредник, который получает данные от Model, обрабатывает их и передает во View через явные вызовы методов. Он знает о существовании View (обычно через протокол) и напрямую управляет его поведением.

// Протокол для View в MVP
protocol UserProfileView: AnyObject {
    func displayUserName(_ name: String)
    func displayError(_ message: String)
}

// Presenter
class UserProfilePresenter {
    weak var view: UserProfileView?
    private let userService: UserService
    
    func loadUser() {
        userService.fetchUser { [weak self] result in
            switch result {
            case .success(let user):
                self?.view?.displayUserName(user.name)
            case .failure:
                self?.view?.displayError("Failed to load user")
            }
        }
    }
}

Характеристики Presenter:

• Сильная связь с View: Presenter вызывает конкретные методы View.
• Управление логикой отображения: Решает, когда и что показывать.
• Часто ручное обновление: Без реактивных паттернов.

2. ViewModel в MVVM (Model-View-ViewModel)

ViewModel представляет собой абстракцию состояния View. Она не имеет ссылок на View и предоставляет данные и команды через наблюдаемые свойства. Связь осуществляется через data binding (например, с помощью Combine или RxSwift).

import Combine

// ViewModel в MVVM
class UserProfileViewModel {
    @Published var userName: String = ""
    @Published var errorMessage: String?
    private let userService: UserService
    
    func loadUser() {
        userService.fetchUser { [weak self] result in
            switch result {
            case .success(let user):
                self?.userName = user.name
            case .failure:
                self?.errorMessage = "Failed to load user"
            }
        }
    }
}

// ViewController (View)
class UserProfileViewController: UIViewController {
    private let viewModel = UserProfileViewModel()
    private var cancellables = Set<AnyCancellable>()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        bindViewModel()
        viewModel.loadUser()
    }
    
    private func bindViewModel() {
        viewModel.$userName
            .sink { [weak self] name in
                self?.nameLabel.text = name
            }
            .store(in: &cancellables)
    }
}

Характеристики ViewModel:

• Нулевое знание о View: ViewModel не содержит ссылок на UI компоненты.
• Реактивное программирование: Изменения свойств автоматически обновляют View.
• Чистая бизнес-логика: Легко тестируется без моков View.

Сравнение на практике

Тестирование Presenter vs ViewModel

// Тест Presenter (нужен мок View)
func testPresenter() {
    let mockView = MockUserProfileView()
    let presenter = UserProfilePresenter(view: mockView)
    presenter.loadUser()
    XCTAssertEqual(mockView.displayedName, "John")
}

// Тест ViewModel (без моков UI)
func testViewModel() {
    let viewModel = UserProfileViewModel()
    viewModel.loadUser()
    XCTAssertEqual(viewModel.userName, "John")
}

Эволюция подходов

• Presenter чаще используется в UIKit без реактивных фреймворков, где требуется явное управление View.
• ViewModel стал стандартом в SwiftUI и современных UIKit-приложениях с Combine/RxSwift, где биндинг упрощает синхронизацию данных.

Выводы

• Presenter — это активный контроллер отображения, который командует View.
• ViewModel — это пассивный источник данных, который предоставляет состояние для View.
• Выбор зависит от стека: MVP для классического UIKit с минимальными зависимостями, MVVM для реактивных приложений с SwiftUI/Combine.
• Ключевой парадигматический сдвиг: от императивного управления (Presenter) к декларативной реактивности (ViewModel).

Оба подхода решают проблему разделения ответственности, но ViewModel обеспечивает более чистую архитектуру благодаря отсутствию зависимости от View и внедрению реактивных принципов.