MVVM Архитектура Android

Question

У меня есть одно действие, и я создал для него одну View-модель. Я создал различные классы, такие как UiUtil (показать, скрыть вид, скрыть панель клавиатуры), сетевой уровень, слой базы данных, AppUtil (для общих функций, таких как проверка коллекции, проверка строки, преобразование даты и т. Д. c)

Мой вопрос заключается в том, что в шаблоне проектирования MVVM Activity может использовать эти служебные классы напрямую, или ему нужно использовать эти классы через модель представления, если это через модель представления, то в модели представления мне нужно написать метод, который просто вызывает вспомогательные классы. метод. как показано ниже TimeDateManager - это служебный класс, используемый в модели представления class HomeViewModel: BaseViewModel() { fun prepareTimeAmPmToDisplay(context: Context, alarm: Alarm): String { return TimeDateManager.prepareTimeAmPmToDisplay(context, alarm) } }

Answer 1

Архитектура не обязательна, она носит рекомендательный характер, поэтому вы можете изменять их использование в довольно широком диапазоне. Единственным ограничителем должен быть здравый смысл (если он присутствует, конечно).

В данном конкретном случае использование служебного класса внутри Activity может быть приемлемым, в зависимости от вашей конструкции ViewModel и способа связи с View (читай Activity).

Например, если у вас есть LiveData, который отправляет какое-то событие (например, данные, загруженные из бэкэнда или триггера тревоги) внутри вашего ViewModel, а ваш View его слушает, я думаю, что это нормально для использования Утилиты внутри Observer в Activity. Особенно, если этот метод utils не зависит от данных ViewModel или Repository. Тем не менее, использование прямых утилит в Activity не ограничивается этим сценарием использования. Существует множество других.

Я понимаю, что в наше время это может быть непопулярным мнением о "чистом подходе", но я считаю, что этот «чистый подход» иногда усложняет вещи там, где это не должно, поэтому, если немного смешивать вещи, это не тормозит общую архитектуру, а скорее делает какую-то вещь более читабельной и простой в обслуживании - я бы go за нее.

Надеюсь, это поможет.

Answer 2

Мой подход к MVVM прост, ViewModel отвечает за бизнес-логи c, работающие с репозиториями (Network, Database, et c.) И всеми кодами не-UI, подготавливающими необходимые данные для UI, просто как документация :

Объект ViewModel предоставляет данные для определенного компонента пользовательского интерфейса c, такого как фрагмент или действие, и содержит бизнес-логику обработки данных c общаться с моделью. Например, ViewModel может вызывать другие компоненты для загрузки данных и может пересылать запросы пользователей на изменение данных. ViewModel не знает о компонентах пользовательского интерфейса, поэтому на него не влияют изменения конфигурации, такие как воссоздание действия при повороте устройства.

С другой стороны, ViewModels не должен хранить контекст (ApplicationContext является исключительным), и предпочтительно, чтобы они вообще не использовали API android, поэтому они становятся более тестируемыми (особенно в случае чисто модульных тестов).

Также мы рекомендуем использовать LiveData в ViewModels и пользовательском интерфейсе должен соблюдать LiveData. Например, в onCreate вашего Activity вы будете вызывать метод loadMainContent() из VM, он вызывает getMainContent(page=1) из репозитория, и репозиторий решит загрузить данные из БД или сети, а результат будет установлен на LiveData, в котором View прослушивает изменения.

TL; DR

Иногда даже лучше вызывать эти утилиты из View, а не из VM. Я почти уверен в вашем UiUtil, также я думаю, что TimeDateManager больше относится к просмотру, чем к логикам c. Кроме того, уровни сети и базы данных более эффективны, если их вызывать из хранилища (которое отвечает за кэширование и т. Д. c.), И виртуальная машина может использовать это хранилище.