Существуют ли сценарии, когда ViewModel должен вызывать методы для View w.r.t. MVVM в WPF?

Question

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

В форме шаблона MVP или PresentationModel (если я не ошибаюсь), представление реализует простой ванильный интерфейс (состоящий из методов, свойств и / или событий). С MVVM кажется, что методы на IView были объявлены вне закона (вместе с самим IView).

Один сценарий, о котором я мог подумать, - это установить фокус на определенный элемент управления в представлении. ( Когда пользователь делает ActionX, фокус должен быть немедленно установлен на FieldY ).

• В MVP я бы написал это как IView.ActivateField (NameConstant), которое вызывал бы докладчик или премьер-министр.
• В MVVM, это, кажется, крайний случай, который требует обходного пути / небольшого количества кода позади. ВМ реализует свойство ActiveField, которое устанавливает в NameConstant. Представление получает событие уведомления об изменении и в обработчике события с выделенным кодом активирует элемент управления Name.

Вышеуказанное - просто исключение из нормы? Или есть другие подобные сценарии, когда виртуальной машине нужно вызывать метод в представлении?

Answer 1

Несмотря на то, что ViewModel не рекомендуется вызывать реальные методы в представлении, существуют ситуации, когда возможность вызывать действие представления является выгодной. Большинство практиков MVVM рекомендуют систему обмена сообщениями, использующую шаблон посредника для обработки ВМ для просмотра связи, и если вы посмотрите на инфраструктуры MVVM, такие как MvvmFoundation , вы часто можете увидеть примеры таких курьерские системы на работе.

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

Messenger.Notify("SetFocusOnElement");

может пригодиться.

Answer 2

Почему вам не разрешено в шаблоне MVVM взаимодействовать с View через интерфейс?

В MVP я бы написал это как IView.ActivateField (NameConstant), которое вызывал бы докладчик или премьер-министр.

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

Более подробную информацию можно найти здесь: WPF Application Framework (WAF) .

Answer 3

Всякий раз, когда вы чувствуете необходимость использовать Code-behind, вы, возможно, можете реорганизовать его таким образом, чтобы создать универсальный многократно используемый элемент управления или класс, который вы можете декларативно использовать в XAML. В вашем случае вы могли бы придумать свой собственный класс FocusListener или тому подобное, чтобы вы могли написать:

<TextBox Text="{Binding SomeStuff}" myCtl:FocusListener.FocusWhen="{Binding SomeStuff}" />

Безусловно, от вашего сценария зависит, сможет ли этот подход вам помочь.

Разумеется, нельзя запрещать расширять доступные классы и элементы управления WPF с помощью своих собственных.