Что такое MVC?

Модель-Представление-Контроллер (MVC) в iOS

MVC (Model-View-Controller) – это фундаментальный архитектурный паттерн, который Apple выбрала в качестве основной парадигмы для разработки приложений на UIKit. Это не просто аббревиатура, а философия разделения ответственности, призванная сделать код более организованным, тестируемым и поддерживаемым. В iOS-разработке MVC является краеугольным камнем, но зачастую требует дисциплины для сохранения своих принципов на практике.

Основные компоненты паттерна

Давайте детально разберем роль каждого из "китов", на которых держится MVC.

1. Модель (Model)

Модель представляет собой слой данных и бизнес-логики приложения. Она совершенно независима от пользовательского интерфейса.

• Ответственность: Хранение данных, их валидация, преобразование и сетевая логика (запросы к API, работа с базой данных).
• Принцип: "Не знает" о существовании View и Controller. Оповещает об изменениях данных (например, через механизмы KVO, делегаты или уведомления NotificationCenter).
• Примеры: Класс User со свойствами name и email, сервис NetworkManager для загрузки данных, класс PersistenceService для работы с CoreData.

// Модель
struct User {
    let id: Int
    var name: String
    var email: String

    // Метод бизнес-логики
    func isEmailValid() -> Bool {
        return email.contains("@")
    }
}

// Сетевой сервис (также часть слоя Model)
class UserService {
    func fetchUser(completion: @escaping (Result<User, Error>) -> Void) {
        // Сетевая логика...
    }
}

2. Представление (View)

Представление – это визуальный слой, то, что видит пользователь. В iOS это, в первую очередь, наследники класса UIView.

• Ответственность: Отображение данных, полученных от контроллера, и передача пользовательских взаимодействий (тапы, свайпы) обратно контроллеру. View должен быть максимально "глупым".
• Принцип: Никогда не обращается к Модели напрямую. Не содержит сложной логики, только базовую конфигурацию внешнего вида.
• Примеры: UILabel, UIButton, кастомные UIView-подклассы, созданные в Interface Builder или кодом.

// Кастомное View (XIB или код)
class ProfileHeaderView: UIView {
    @IBOutlet private weak var avatarImageView: UIImageView!
    @IBOutlet private weak var nameLabel: UILabel!

    // View только конфигурирует себя на основе переданных данных
    func configure(with name: String, avatar: UIImage?) {
        nameLabel.text = name
        avatarImageView.image = avatar
    }
}

3. Контроллер (Controller)

Контроллер выступает в роли посредника между Моделью и Представлением. В iOS это чаще всего наследники UIViewController.

• Ответственность: Получение данных от Модели, их подготовка и передача во View для отображения. Обработка событий от View и обновление Модели в соответствии с действиями пользователя. Управление жизненным циклом экрана.
• Принцип: Связывает Model и View, но в идеале не должен содержать тяжелой бизнес-логики или сложной логики отображения.

// Контроллер
class ProfileViewController: UIViewController {
    @IBOutlet private weak var headerView: ProfileHeaderView!

    // Зависимость от Модели (сервиса)
    private let userService = UserService()
    private var user: User?

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

    private func loadUserData() {
        // Контроллер запрашивает данные у Модели
        userService.fetchUser { [weak self] result in
            switch result {
            case .success(let user):
                self?.user = user
                // Контроллер передает данные во View
                self?.headerView.configure(with: user.name, avatar: nil)
            case .failure(let error):
                // Обработка ошибки (показать alert)
                print(error)
            }
        }
    }

    // Обработка действия от View (например, нажатие кнопки "Сохранить")
    @IBAction func saveButtonTapped(_ sender: UIButton) {
        guard var user = user else { return }
        user.name = "Новое имя"
        // Контроллер обновляет Модель (здесь может быть вызов userService.updateUser)
        updateView()
    }

    private func updateView() {
        guard let user = user else { return }
        headerView.configure(with: user.name, avatar: nil)
    }
}

Поток данных в MVC

1. Пользователь взаимодействует с View (тапает кнопку).
2. View уведомляет Controller (через @IBAction или делегата).
3. Controller обрабатывает действие: может запросить новые данные у Model или обновить существующие.
4. Model изменяется и оповещает Controller об изменениях (асинхронно).
5. Controller получает обновленные данные от Model, подготавливает их (форматирование строк, преобразование типов) и передает во View.
6. View перерисовывается, отображая новые данные.

Проблема "Massive View Controller" и эволюция подхода Apple

Классическая проблема "чистого" MVC в UIKit – это раздувание контроллеров (Massive View Controller). Поскольку UIViewController по умолчанию является владельцем View (view property) и единственным обработчиком логики, в него часто "стекается" всё: сетевая логика, парсинг JSON, работа с базой данных, сложная подготовка данных для отображения, анимации и т.д.

Для борьбы с этим Apple в последние годы активно продвигает модификации и альтернативы:

• MVVM (Model-View-ViewModel): Вводится ViewModel – объект, который готовит данные специально для отображения, освобождая ViewController от этой задачи. ViewController становится преимущественно "владельцем вида" и связующим звеном.
• Координаторы (Coordinators): Паттерн для вынесения навигационной логики из контроллеров, что делает их более переиспользуемыми и тестируемыми.
• Композиция (Composition): Разделение большого контроллера на несколько дочерних (child view controllers), каждый со своей зоной ответственности.
• Фреймворк SwiftUI: Предлагает декларативный подход, который фундаментально меняет архитектуру, смещая акцент на State и View, а Controller в его классическом виде исчезает.

Итог: Понимание классического MVC критически важно для любого iOS-разработчика, так как это основа, на которой построен весь UIKit. Однако в современных реальных проектах этот паттерн почти всегда используется в гибридной форме, обогащенный практиками из MVVM, координаторов и сервис-ориентированной архитектуры для достижения чистого, модульного и поддерживаемого кода.