Android mvvm команды из view
Почему в MVVM View не должно говорить ViewModel что делать?
Т.е. почему во view не должно быть такого, viewModel.loadData() или viewModel.updateData или viewModel.setName()
А принято public методы viewModel именовать примерно следующим образом:
fun nameChanged(name: String) fun updateDataRequested() А внутри уже ViewModel решает как на это реагировать..
Может есть статьи где это объясняется?
Ответы (1 шт):
Задача View - показывать пользователю состояние приложения, а так же сообщать приложению о действиях пользователя, то есть обрабатывать пользовательский ввод.
Задача View Model - предоставить View данные, к которым View может обращаться и команды, которые View может вызывать. Так же View Model сообщает View, когда данные изменились, чтобы последняя оперативно отобразила эти изменения пользователю.
Задача Model - принимать и отправлять данные.
Т.е. почему во view не должно быть такого, viewModel.loadData() или viewModel.updateData или viewModel.setName()?
Ну почему же не должно? Представим что loadData() - команда, некое свойство вьюмодели loadDataCommand, которое содержит внутри себя метод execute(). Вы объявляете во View вызов этой команды, скажем при нажатии на кнопку. При этом View не знает, что произойдет когда команда выполнится, она просто делает вызов, и всё. Дальше уже View Model сама изменяет свои данные и сообщает интерфейсу где что поменялось.
И здесь материализуется четкая грань в характерах задач, которые решают View и View Model, с которых я начал писать ответ.
View знает, где у вьюмодели какие свойства, знает где команды, но она ничего не знает о том, что делают эти команды, и когда обновляются свойства, она подписалась на события вьюмодели и ждёт.
Что это нам дает:
- Можно перепилить или заменить View полностью, оставляя вьюмодель неизменной.
- Универсальность View Model. Грубо говоря у меня в C#/.NET может быть 3 приложения: WPF, Xamarin и Avalonia, использующие общую библиотеку с вьюмоделями.
- Изменение Model не влияет на View. Например вчера я использовал XML-RPC API, сегодня сервер новый, и я использую JSON REST API. Model я переписал, в View и View Model трогать не пришлось (а у меня 3 разных вьюхи, помните?).
Подводя итог, скажу что разделение приложения на 3 слоя: представление (View), бизнес-логика (View-Model) и связь с данными (Model) - делает разработку практически любого приложения в 3 раза проще. И чем слабже эти слои связаны - тем удобнее приложение дорабатывать.
Вы сталкивались с ситуацией, когда изменение кода в одном классе влечёт за собой изменения еще в 3 местах приложения? А потом на тестах выясняется, что мест было не 3, а 5, и вы идёте фиксить баги. Именно поэтому и придуманы все эти шаблоны проектирования - облегчить жизнь разработчику.
А чтобы было легче понимать, как организовать объектную модель приложения и окончательно подружиться с тремя принципами ООП - еще придуманы принципы SOLID, которые являются прекрасным дополнением к основным шаблонам проектирования, например к MVVM.