MVVM как шаблон предназначен для разделения проблем, улучшения тестируемости вашего кода и т. д., поэтому ваша ViewModel должна только заниматься применением бизнес-правил и предоставлением данных для вашего представления.
Вам нужно будет использовать это в сочетании с каким-то шаблоном MVC, где заботой контроллера является обработка навигации/состояния приложения и т. д.
(редактировать) Например, представьте, что ваше приложение имеет экран входа в систему, поэтому вы создаете LoginView, который содержит имя пользователя и пароль; вероятно, кнопка «ОК» и кнопка «Отмена».
Вы создаете класс LoginViewModel для привязки этого представления и обработки логики входа в систему в этом классе.
Но как только приложение войдет в систему, ViewModel не несет ответственности за то, чтобы знать, куда идти дальше; или какой вид отображать следующим.. может быть, вы хотите перейти к последнему экрану, на котором этот пользователь был в предыдущий раз, когда они вошли в систему? Может быть, он переходит на экран по умолчанию, в соответствии с профилем пользователя? Это решение не имеет ничего общего с функцией входа в систему...
Таким образом, если вы создаете класс Controller, вы можете: Создать экземпляр класса LoginViewModel, а затем, в зависимости от результата входа в систему, применить необходимые бизнес-правила для удаления LoginViewModel из области действия и создать новую ViewModel (например, HomePageViewModel) и т. д. ..
Наконец, вам нужно сообщить приложению, какие представления использовать для каждой виртуальной машины, используя шаблоны данных.
Конечно, есть куча других способов содрать шкуру с этого конкретного кота... это всего лишь одна идея...
Пока остается основная концепция: используйте MVVM для преодоления разрыва между представлением и моделью чистым, тестируемым способом... не пытайтесь сделать его «одним шаблоном, подходящим для всех» :)
ХТХ :)
person
kiwipom
schedule
06.10.2009
