Ответ.

История вопроса

Паттерн Model-View-Controller (MVC) — это классический архитектурный паттерн, появившийся задолго до Swift и используемый для разделения данных, пользовательского интерфейса и управляющей логики. В истории iOS-разработки MVC был провозглашён Apple как основной архитектурный паттерн для построения приложений на Objective-C и Swift.

Проблема

Главная проблема стандартного MVC — со временем контроллеры становятся "Massive View Controllers", объединяя в себе бизнес-логику, взаимодействие с моделью, обработку пользовательского ввода и даже логику отображения. Это приводит к снижению читаемости, повторному использованию и тестируемости кода.

Решение

В Swift MVC реализуется с использованием классов UIViewController для контроллера, моделей как структур или классов, а также UIView для построения интерфейса. Контроллер связывает модель и представление, инициируя обновление интерфейса при изменениях данных.

Пример кода:

struct User {
    let name: String
    let age: Int
}

class UserView: UIView {
    let nameLabel = UILabel()
    func display(user: User) {
        nameLabel.text = "\(user.name), \(user.age) лет"
    }
}

class UserController: UIViewController {
    var user: User?
    var userView: UserView!

    override func loadView() {
        userView = UserView()
        view = userView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        if let user = user {
            userView.display(user: user)
        }
    }
}

Ключевые особенности:

Связь между слоями через controller.
Модель не знает о view.
Логика пользовательского ввода и навигации в контроллере.

Вопросы с подвохом.

Можно ли допускать зависимости между View и Model напрямую в MVC?

Нет, View не должен взаимодействовать с Model напрямую. Вся коммуникация происходит только через Controller; иначе модель "узнаёт" о представлении, что нарушает принцип разделения ответственности и мешает масштабированию.

Может ли Controller содержать данные и логику бизнес-уровня?

Часто ошибочно считают, что контроллер может содержать бизнес-логику. Фактически бизнес-логику стоит уносить в Model или отдельные сервисы, а контроллер должен только управлять жизненным циклом View и согласованием данных.

Как бороться с массивными контроллерами (Massive View Controller)?

Для борьбы с массивными контроллерами выносите обработку данных из контроллера в Model или сервисы, используйте делегаты, паттерны делегирования и композиции. Делайте отдельные классы для настройки View или вносите логику отображения непосредственно в View.

Типовые ошибки и анти-паттерны

Модель общается напрямую с View
Массовый контроллер (Massive View Controller)
Хранение состояния View в контроллере
Отсутствие выделения бизнес-логики в Model

Пример из жизни

Негативный кейс

В проекте контроллер хранил сразу и данные пользователя, и их обработку, и код отображения. Повторно использовать логику в другом контроллере оказалось невозможно, протестировать бизнес-логику было очень трудно.

Плюсы:

Быстрый старт, мало классов

Минусы:

Плохо читаемый код
Трудности с поддержкой и тестированием

Позитивный кейс

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