MVVM, ViewModel, Model & MessageBoxes

Question

Я понял базовый принцип отказа от MessageBox в коде ViewModel или в коде модели, но вместо этого использовал обратный вызов какого-либо типа, будь то интерфейс или декларация func, которая добавляется к ViewModel при построении.

До сих пор так хорошо.

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

Но что, если Модель делает тонны вещей прежде, чем осознать необходимость обратной связи с пользователем? Предоставляю ли я модели также функцию обратного вызова?

Должен ли он быть разработан по-разному?

Любые советы приветствуются. :-)

Answer 1

ОК, я думаю, что понял это.

В моей модели я инкапсулировал каждый вызов файловой системы в самозаписываемом интерфейсе, который называется IIOServices и все мои вызовы пользовательского интерфейса в интерфейсе IUIServices.

UIServices используют только стандартные типы данных или самоопределенные перечисления и ничего из пространства имен System.Windows.Forms или System.Windows.

Тогда клиенты модели несут ответственность за предоставление реализации для доступа к FileOpenDialogs и MessageBoxes и тому подобное в любом случае.

Мой пример кода для этой реализации (которая хранится мало для изучения опыта) можно найти здесь, если кто интересуется:

MVVM with MessageBoxes sample code

Answer 2

Вы открываете публичное мероприятие и можете просмотреть (.xaml.cs), чтобы прослушать его при запуске. Код по-прежнему будет запускаться в рабочем потоке, но бэкэнд-логика не будет висеть во время модульного тестирования.

Answer 3

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

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

Вы можете реализовать свои методы модели более мелкозернистые и позволить прикладному слою координировать операции вашей модели. Таким образом, всякий раз, когда выполняется операция модели и требуется ввод пользователя, уровень mvvm может повысить обратный вызов.

Пример:

// method of your view model/application layer 
public void InteractiveProcessing() 
{ 
    // business logic is separated in smaller chunks 
    model.DoFirstPartOfOperation(); 
    // check if model needs additional user input 
    if(model.NeedsInput) 
     // raise callback here, let user enter input etc... 
    // continue processing with user input 
    model.DoSecondPartOfOperation(userInput); 
} 

Конечно, это имеет смысл только если вы могли бы разделить бизнес-логику на более мелкие части.