«Apple не использует MVVM».
«MVVM — неправильный архитектурный шаблон».
«MV — это то, как это должно быть сделано».
Слышали подобные утверждения раньше?
Я точно слышал — особенно в Твиттере (или как он там сейчас называется). В сообществе SwiftUI идёт непрекращающаяся борьба за то, какая архитектура «правильная». И знаете что? Я почти поверил в эту точку зрения… пока недавно не посмотрел официальный обучающий ролик Apple.
И тут внезапно. Прямо посреди этого безупречного кода Apple оказалась ViewModel — делающая то, что у неё получается лучше всего: управление логикой, хранение состояния и поддержание чистоты и лаконичности представления SwiftUI.
Взгляните на этот шедевр из обучающего ролика:
Да, это прямо @State var viewModel: StickerViewModel. Apple не просто одобряет ViewModel — они активно используют их, чтобы научить новичков создавать приложения.
Но подождите, разве SwiftUI не «декларативный»?
Да, это так! SwiftUI — это декларативный, реактивный и все эти модные словечки. Но это не значит, что мы должны запихивать всю логику внутрь View, как всю начинку в индейку на День благодарения.
Давайте сыграем в небольшую игру: представьте, что вы создаёте простое приложение для стикеров.
Теперь спросите себя:
- Должно ли представление знать, как получать фотографии?
- Должно ли оно обрабатывать бизнес-правила, такие как «если фотография неактивна, показать плейсхолдер»?
- Должно ли оно управлять логикой отображения экрана?
Абсолютно нет.
В тот момент, когда ваше View становится мастером на все руки, его тестирование, отладка и масштабирование превращаются в кошмар. Вот тут-то и приходит на помощь ViewModel — как тихий незаметный ниндзя, который делает грязную работу, чтобы ваше представление могло просто… ну, показывать то, что нужно.
MVVM против MV против «Просто здравый смысл»
Давайте быстро расшифруем аббревиатуры:
- MV (Model-View): всего два слоя. Представление напрямую взаимодействует с моделью. Чисто для простых вещей, неряшливо для чего-либо сложного.
- MVVM (Model-View-ViewModel): Вводит ViewModel в качестве посредника для изоляции логики/состояния. Отлично подходит для ясности и тестируемости.
- MVOCDTFC (Model-View-Other-Crazy-Design-That-Fits-Context): Ладно, я это придумал — но иногда архитектура действительно зависит от сложности вашего приложения и вашей команды.
Вот в чем загвоздка:
Архитектура — это не догма. Это всего лишь инструмент.
Используйте ее для разделения задач, упрощения тестирования и масштабирования кода.
Вы можете написать плохой MVVM. Вы можете написать красивый MV.
Но сам шаблон — не злодей, им может быть только ваша реализация.
Мнение читателя: Представления в SwiftUI — это не то, что вы думаете
Один меткий комментарий читателя действительно точно отражает суть SwiftUI:
Чтобы иметь ViewModel, сначала нужно заиметь View… но в SwiftUI представления не существует! Это просто фрагменты данных (значения, а не объекты), которые сравниваются (фреймворком, а не вами) для создания физического представления. Ваша задача — объявить, как данные сопоставляются с физическими представлениями (функция body) и вызывать действия (чистые функции, а не методы). Важно отметить, что состояние не принадлежит структуре представления — структура неизменяема. Фактическое состояние (и другие динамические свойства) управляются фреймворком. Вы просто знаете, как их использовать, через wrappedValue и projectedValue.
Это блестящее резюме.
SwiftUI не предоставляет вам долгоживущие представления, как UIKit. Вы не храните состояние и не управляете жизненными циклами. Вместо этого SwiftUI постоянно переоценивает представление в зависимости от состояния. Фреймворк управляет тем, когда и как сохранять состояние и отображать представления.
Так что же это значит для MVVM?
Это значит, что традиционный граф объектов MVVM здесь не совсем применим. Нет постоянного представления, ссылающегося на ViewModel. В лучшем случае вы переносите часть логики на другой объект — но это не делает его MVVM в классическом смысле.
Спасибо комментатору за то, что он обратил на это внимание. Иногда один комментарий может сказать то, что требует объяснения в десятке абзацев.
Давайте упростим с помощью аналогии
Представьте себе ваше представление SwiftUI как официанта в ресторане.
Вы бы ожидали от официанта:
- Приготовления еды?
- Пополнения запасов?
- Составления меню?
Нет. Это работа шеф-повара (он же ViewModel). Работа официанта — представить что-то клиенту и передать ему данные — просто и понятно.
Ваше представление должно представлять данные, а не вычислять их.
А как насчет тестирования?
С MVVM вы можете легко писать модульные тесты для логики ViewModel, не запуская предварительный просмотр SwiftUI или симулятор. Речь идет не только о поддержании порядка — речь идет о возможности быстрее выпускать качественный продукт и исправлять ошибки до того, как они попадут в продакшн.
Честно говоря: даже Apple не придерживается архитектуры
Давайте будем реалистами: Apple не навешивает ярлыки на свои архитектуры. Они делают то, что работает, в зависимости от контекста.
Но когда Apple использует ViewModel в своих образовательных материалах — например, в фрагменте кода StickerCarousel — это явный сигнал. Они говорят:
Используйте то, что работает. Но подумайте о разделении ответственности.
И именно это мы и должны делать.
Заключительные мысли
Забудьте о ярлыках. Сосредоточьтесь на:
- Ясности: Может ли кто-то другой прочитать и понять ваш код?
- Разделении ответственности: Четко ли распределены обязанности?
- Тестируемости: Можете ли вы писать тесты без загрузки пользовательского интерфейса?
Назовите это MVVM, MV или «Компонентно-ориентированной пиццо-архитектурой». Если это делает ваш код SwiftUI чистым, поддерживаемым и масштабируемым — это правильная архитектура.
Поэтому в следующий раз, когда кто-то скажет: «Apple не использует MVVM», просто улыбнитесь, покажите им скриншот из учебного пособия и скажите:
«Вы уверены в этом?»