Паттерн проектирования MVVM Android

Рейтинг: 0Ответов: 1Опубликовано: 03.05.2023

Пытаюсь написать Android-приложение для просмотра и публикации статей в соответствии с требования паттерна MVVM. С Model и Repository разобрался, но возникли трудности с взаимодействием View и ViewModel. Правильно ли я понимаю, что:

View только отображает представления или группы представлений (кнопки, иконки, текст и т.п.). View должна быть по возможности как можно "тупее", а логику по типу: "Если длина строки, полученной из EditText, не соответствует условию - отображаем соответствующее предупреждение, иначе - вызываем метод для ее отображения" помещаем во ViewModel, так ли это?

Ответы

▲ 1Принят

Не совсем так.

Например: при регистрации нужно ввести логин пользователя длиной не менее 5 и не более 40 символов (ограничение поля БД), а также он может содержать только латинские буквы, цифры и подчеркивание.

Здесь первое, что бросается в глаза - это максимальная длина. Чтобы упростить пользователю жизнь, проще всего внедрить ограничение на максимальную длину прямо во View, просто задав ее в свойстве контрола.

А все остальное можно отслеживать в VM. Другими словами в рамках View можно управлять поведением так, чтобы снизить вероятность выдачи ошибок. При этом, в VM валидировать максимальную длину все равно надо. VM не должна знать про поведение View, VM сама за себя должна уметь постоять.

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

То есть степень навороченности View (как и любого другого слоя) по сути ничем не ограничена. View отвечает за пользователя, VM за доступность данных (в обе стороны) и их обработку, Model за их целостность и сохранность.


А чтобы понять смысл MVVM во взаимодействии между слоями - надо представить ситуацию, что один из слоев может быть полностью заменен на другой совместимый, и при этом не придется менять ни строчки кода в других слоях.

Например, я написал MVVM приложение под Xamarin, а через год решил выпустить WPF версию этого приложения. Я беру VM и Model без изменений и полностью переписываю View под WPF. Или вышла новая технология MAUI, я беру VM и Model и переписываю View. Или раньше я работал с сервером через JSON API, а потом решил перейти на gRPC, я беру View и VM и полностью заменяю Model.

Другими словами, MVVM не про умственные способности каждого из слоев, MVVM - про взаимодействие между ними. А все что происходит внутри конкретного слоя и не затрагивает его внешний API, не относится к MVVM совсем.