Роль ВМ в MVVM - должна ли она обрабатывать все и почему?

Question

Где конкретно находится предел для принятия виртуальной машины, чтобы она могла лучше соответствовать конкретному представлению? Пример:

В пользовательском интерфейсе должна быть команда (кнопка ex), которая должна позволять добавлять новый элемент. Дополнительным требованием может быть то, что новый элемент должен быть выбран, должен быть видимым на элементе управления (скажем, элемент управления TreeView) и начать редактирование нового элемента (чтобы изменить предопределенное значение, которое было установлено в ВМ). Предположим, что контроль не имеет автоматического механизма для достижения этого, поэтому нам нужно сделать это вручную. Таким образом, поток выполнения выглядит следующим образом:

1. вызвать команду add на виртуальной машине - готово - это xaml View.
2. устанавливает SelectedItem в новый элемент (обычно мы привязываем свойство SelectedItem элемента управления к свойству VM CurrentItem, а затем просто назначаем новый элемент CurrentItem.
3. убедитесь, что новый элемент виден на элементе управления - это должно быть сделано в коде View позади.
4. Начать редактирование - это должно быть сделано в коде View.

Теперь, поскольку повсюду в сети есть статьи об использовании сообщений практически для всего, вопрос:

Что я сломаю, если сделаю это простым старым способом? Я использую событие Click вместо привязки команды при добавлении нового элемента, и в методе я делаю это:

// in View's Click event handler
ViewModel.AddCommand.Execute(null);
EnsureVisibleSelectedItem();
BeginEdit();

.. чисто и ясно! И что я получу, если сделаю это с помощью сообщений:

// in ViewModel's AddCommand
AddNewItem();
SetCurrentItem();
SendMessageToEnsureVisibleSelectedItem();
SendMessageToBeginEditSelectedItem();

... где View зарегистрировался для получения этих двух сообщений.

Любой свет на это очень ценится. По моему мнению, пользовательский интерфейс может измениться, и виртуальная машина должна быть в состоянии принять новый пользовательский интерфейс, не внося изменений в себя, поэтому я не совсем понимаю текущую политику MVVM, которая проповедуется в Интернете.

Answer 1

Я бы сказал «сделай это проще».

Что действительно важно в MVVM это:

• что не зависит отпредставление должно идти в ViewModel (ваша ViewModel не должна знать о представлении каким-либо образом - не только по ссылке на объект)
• все остальное в представлении и его коде позади .

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

Чтобы ответить на ваш вопрос, вы ничего не нарушаете в письменной форме:

// in View's Click event handler
ViewModel.AddCommand.Execute(null);
EnsureVisibleSelectedItem();
BeginEdit();

Все, что не связано спредставление находится в ViewModel, все остальное в View / code-behind.Это нормально.

Нет, если я посмотрю на ваш второй пример:

// in ViewModel's AddCommand
AddNewItem();
SetCurrentItem();
SendMessageToEnsureVisibleSelectedItem();
SendMessageToBeginEditSelectedItem();

AddNewItem в порядке (не относится к представлению), SetCurrentItem в порядке (не связано свид), а как насчет SendMessageToEnsureVisibleSelectedItem и SendMessageToBeginEditSelectedItem?EnsureVisible обычно полезен для древовидной структуры, но что если ваш вид не был построен с древовидной структурой?Что если элемент управления автоматически сделает видимым новый выбранный элемент?Конечно, вы можете проигнорировать это сообщение, но вы бы написали какой-то бесполезный код во ViewModel, потому что вы думали, что вашему представлению он понадобится для отображения пользовательского интерфейса.

Обычно вы пишете здесь некоторый код в ViewModel, который знает окак должно работать представление. Да, вы сократили количество строк в коде, но вы определенно нарушили шаблон .

Ваш "старый способ" на самом деле является хорошим способом для ваших нужд.Ваша ViewModel не знает о представлении, вот что важно.