MVVM не обязательно связывать с RxSwift, но это лучше.
Для разработки мобильных приложений MVVM - это современная архитектура. Он выполняет лучшее разделение проблем, чтобы сделать код более чистым. Как мы обсуждали в предыдущей статье, MVVM улучшил взаимодействие между бизнес-логикой и представлением за счет привязки переменных в ViewModel к элементам ViewController. В этой статье будут представлены два способа реализации MVVM.
MVVM с Swift
Чтобы выполнить привязку двумя способами без зависимости, нам нужно создать собственный Observable. Вот код ниже:
Observable<T> - это настраиваемый класс, который может содержать значение типа T. Если значение изменяется, мы запускаем didSet, который вызывает функцию привязки, передавая значение обратно вызывающей стороне. В качестве конкретного примера давайте проверим код здесь:
Если мы сосредоточимся на части 1, у нас есть cellViewModels привязка к reloadTableViewClosure, isLoading привязка к updateLoadingStatus и alertMessage привязка к showAlertClosure.
В ViewController мы связываем замыкания с элементами пользовательского интерфейса, после чего можем инициировать любой запрос асинхронизации в ViewModel. В приведенном выше коде это номер 3 initFetch(). Он запрашивает API и, если произошла ошибка, обновляет переменную alertMessage, если запрос выполнен успешно, обновляет переменную cellViewModels. Оба изменения переменных обновят пользовательский интерфейс в ViewController.
Там у нас двусторонняя привязка.
MVVM с RxSwift
С RxSwift двустороннее связывание становится проще. Вот код:
В приведенном выше коде мы можем легко определить, что Input содержит наблюдаемую переменную для приема события от ViewController и Output с наблюдаемой переменной для привязки элементов пользовательского интерфейса в ViewController. Функция init устанавливает зависимости и обрабатывает данные из API, а также инициализирует ввод и вывод.
Вот код ViewController:
В ViewDidLaod() мы применяем setupBinding() и setupErrorBinding(), чтобы связать элементы пользовательского интерфейса с наблюдаемыми в ViewModel. Когда вся привязка готова, у нас есть self.articleViewModel.input.reload.accept(()), чтобы активировать триггер потока данных. Затем у нас есть асинхронные данные из Api, которые могут автоматически отражаться на ViewController.
Последние мысли
Вот графики, показывающие, как работает двусторонняя привязка.
Перед запросом данных элементы пользовательского интерфейса должны сначала связать вывод и ввод в ViewModel. Как будто туннель застраивают.
Затем мы можем запустить поток данных, вот график. ViewController может иметь несколько элементов пользовательского интерфейса, привязанных к нескольким входам и выходам. С таким потоком данных код будет более читабельным и коротким.
MVVM с Rxswift не идеален. Вот недостатки, которые делают Rxswift не лучшим выбором.
- Кривая обучения: крутая кривая обучения затрудняет вовлечение новых разработчиков в проект (а ближе к концу проекта - совершенно непрактично). Это причина №1, по которой мы должны избегать RxSwift: когда придет время, мы не сможем добавлять разработчиков в проект, если они уже не ветераны Rx.
- Отладка преобразований данных Rx ужасна. Когда Rx работает так, как задумано, это на грани волшебства. Когда возникает проблема, процесс отладки значительно усложняется. Любая точка останова, которую вы попадете в поток данных, представит стек трассировки с более чем 40 записями с десятками непостижимых внутренних методов Rx, разделяющих и скрывающих код, который мы на самом деле написали.
RxSwift не может значительно сократить время разработки в целом. Он просто превращает проблемы в какие-то новые проблемы. Если команда не готова к Rx и на рынке действительно сложно найти разработчиков RxSwift, то Rx может быть не лучшим выбором. Лично я всегда использую MVP в сочетании с MVVM и Rxswift. Я считаю, что Rxswift может гладко решить проблемы с асинхронизацией, но у нас есть много случаев без асинхронных запросов. В этом случае MVP в порядке.
Надеюсь, эта статья вдохновила вас на создание собственной архитектуры приложения. Вы можете оставлять комментарии к этой статье. Я ценю любое предложение.
