Search
Write a publication
Pull to refresh

Comments 4

Fragment/Activity - это скорее Controller с возможностью сохранять данные в бандл, а не ViewModel

Это сильно зависит с какой стороны смотреть и к какой части статьи комментарий.

В самом конце речь идет про сопоставление сущностей верстки с сущностями кода чернз привязку с помощью data binding, и с этой точки зрения они являются vm из шаблона.

Но конечно же, сам по себе такой сферический конь в вакууме не имеет смысла, т.к. гораздо логичнее сразу вынести из них все что возможно, чтобы оставить из максимально тонкими.

Пс. Во ViewModel от гугл так же можно сохранять состояние и это тогда тоже контроллер? Или о каком вообще контроллере идет речь?

я не говорил что контроллер должен сохранять состояние. я не согласился с этим тезисом: "Из этого следует, что в Android: View это XML, а Activity/Fragment/внезапно класс View — это ViewModel" , потому что эта сущность фреймворка помогает обрабатывать пользовательский ввод/нажатия на кнопки и позволяет реагировать на эти события, а также на события жизненного цикла. Даже если у тебя есть любого вида датабиндинг + XML + Fragment/Activity

Связку xml + код (activity/fragment/view) можно сделать различными способами.

Как прямое управление xml = mvp
val textView = findById... и другие способы получить саму View
textView.text = "Hello World"

Как привязку данных к xml = mvvm
val text : LiveData
val binding: TextBinding = DataBindingUtil.setContentView(this, R.layout.text)
text = "Hello World"

И в таком максимально прямом подходе, можно сказать, что Activity это Presenter/ViewModel в понятии шаблона. И это дает законные основания из далее следующих классов, которые с такого ракурса будут являться частью Model, делать огромные вундервафли которые и в сеть сходят и про базу данных знают.

НЕ НУЖНО ТАК ДЕЛАТЬ.

Пример выше это только теоретическая точка зрения на код и шаблоны, которая позволяет понять, что есть разные взгляды на одни и те же вещи.

И если вы делаете большие и уродливые Presenter/ViewModel, просто вспоминайте, что вы сейчас попутали понятия и используете Activity как сущность ViewModel, а класс ViewModel как часть Model.

Если же вы хотите чтобы ваш класс ViewModel оказался сущностью ViewModel, то он должен только проанализировать действие пользователя, попросить модель выполнить работу и переделать результат работы в данные для View.

Любая дополнительная логика превратит ваш клаcc ViewModel в часть Model.

Я специально даю такую интерпретацию шаблонов, чтобы заставить читателя задуматься над тем, что ViewModel должна быть тонкой и тупой.

Sign up to leave a comment.

Articles