Служба взаимодействия против объектов запроса взаимодействия

Question

Я хотел бы знать, что при использовании Prism объекты запросов на взаимодействие предпочтительнее, чем использование шаблона службы взаимодействия. Что касается меня, служба взаимодействия должна использоваться в простых случаях, то есть, когда у вас есть стандартное всплывающее сообщение, и только текстовое содержимое будет изменено. С другой стороны, Объекты Запроса на Взаимодействие больше подходят, когда пользовательский интерфейс более сложный. Но Interaction Service намного проще в реализации и требует меньше кода. Что ты думаешь?

Answer 1

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

Какое окно вы должны предоставить в качестве родителя окна сообщения из модели представления или реализации службы? Если вы выбираете Application.Mainwindow, вы делаете огромное предположение об общей структуре приложения.

Единственная сущность в процессе, которая знает , как отображать взаимодействие, - это представление. Использует ли это окно сообщения или наложение на странице.

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

Answer 2

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

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

Рассмотрим базовый интерфейс службы взаимодействия:

public interface IInteractionService{
    MessageBoxResult ShowMessageBox(string messageBoxText, string caption, MessageBoxButton button);
}

Из наблюдения за интерфейсом довольно очевидно, какой тип поведения будет генерировать ShowMessageBox. Это дает ViewModel некоторую степень контроля с точки зрения определения того, какой тип взаимодействия он ожидает. Проблема этого подхода заключается в том, что ваша ViewModel теперь зависит от IInteractionService, а также от явных ожиданий в поведении взаимодействия. Это может сделать вашу ViewModel менее пригодной для повторного использования.

С объектами взаимодействия вы можете возложить больше ответственности за поведение взаимодействия на представление. Другими словами, вы можете изменить поведение и внешний вид взаимодействия, не влияя непосредственно на ViewModel. Например, V1 запроса взаимодействия может отображать простой MessageBox. V2 запроса взаимодействия может быть более сложным диалогом, требующим большего взаимодействия с пользователем, чем простое нажатие кнопки. С этим изменением поведения взаимодействия можно управлять, не требуя модификации ViewModel. Это может быть полезно, если у вас есть проектировщик пользовательского интерфейса, работающий над проектом, который хочет, чтобы опция менялась или изменяла поведение или внешний вид представления, связанного с запросом взаимодействия.

Вы можете использовать обе стратегии, если хотите. Другими словами, Служба взаимодействия для общих поведений взаимодействия и Объекты взаимодействия для более сложного поведения.

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