Перейти на PRO

В архитектуре MVVM на Swift, модели данных следует объявлять классами или структурами?

Тип вопроса: Архитектура Вероятность: 10% Категория: IOS Разработчик

Ответ

Для моделей данных в MVVM на Swift предпочтительнее использовать структуры (struct).

Причины:

  • Семантика значений (Value Semantics): Структуры копируются при передаче, что предотвращает неожиданные побочные эффекты и делает поведение предсказуемым.
  • Потокобезопасность: Поскольку данные копируются, их изменение в одном потоке не затрагивает другие.
  • Автоматический синтез инициализатора: Не нужно писать init для простых моделей.

Пример модели-структуры:

struct User {
    let id: UUID
    var name: String
    var email: String
}

Когда использовать класс (class):

  • Для ViewModel: ViewModel обычно реализуют как class, поскольку они хранят состояние, управляют жизненным циклом и должны быть ссылочным типом для обновления View.
  • Для интеграции с Objective-C (наследование от NSObject).
  • Когда требуется явная ссылочная семантика (например, общее изменяемое состояние).

Итог: Модели — struct, ViewModel — class.

Ответ 18+ 🔞

Давай разберём эту тему, как будто я тебе на кухне объясняю, пока чайник кипит.

Смотри, чтобы не накосячить с архитектурой, нужно запомнить простое правило, которое даже на холодильник магнитиком прилепить можно: Модели — это struct, а ViewModel — это class. Всё, конец лекции. Шучу, сейчас объясню, почему это не просто чья-то блажь, а вполне себе логично.

Почему модели — это struct? Представь, что твоя модель данных — это как наличные деньги. Ты передал сотку другу — у тебя её нет, а у него есть. Это его сотка, пусть с ней делает что хочет. Так вот, структуры (struct) работают по такому же принципу — семантика значений. Когда ты передаёшь структуру в функцию или присваиваешь новой переменной, создаётся её новая, независимая копия.

struct User {
    let id: UUID
    var name: String
    var email: String
}

Представь, что у тебя в одном месте кода user.name = "Вася", а в другом, глубоко внутри какой-нибудь функции, ты не глядя меняешь это же имя. Если бы это был класс, то имя поменялось бы везде, и Вася неожиданно стал бы Петей во всём приложении — вот это был бы пиздец, отладка на неделю. А структура скопировалась, и ты меняешь имя только в этой конкретной копии. Побочных эффектов — ноль. Это, блядь, святое.

Плюс, структуры по умолчанию потокобезопасны в этом контексте. Раз каждая сущность — своя копия, то хоть в двадцати потоках её меняй, друг другу они мешать не будут. И инициализатор компилятор сам сгенерирует — красота.

А когда тогда class? А вот ViewModel — это уже не просто данные, это, сука, состояние и логика. Это как дирижёр оркестра. Ему нужно жить долго, хранить в себе ссылки на сервисы, меняться и уведомлять View об этих изменениях. Ему нужна ссылочная семантика. Чтобы десять разных экранов смотрели на одну и ту же ViewModel и видели актуальное состояние. За это и отвечает class.

Итог, который нужно выжечь на подкорке:

  • Модель (User, Product, Order) — это struct. Данные, которые просто описывают сущность. Копируются, как наличные.
  • ViewModel (UserViewModel, ProductViewModel) — это class. Состояние и бизнес-логика. Живёт, меняется и управляет всем процессом.

Если начнёшь делать модели классами, а ViewModel структурами — готовься к волшебному миру необъяснимых багов, где всё меняется само по себе. Не усложняй себе жизнь, иди проверенным путём. Всё гениальное — просто, как ёбушки-воробушки.

© ХакСобесов, 2026
support@hacksobesov.com