交互服务与交互请求对象

Question

我想知道当使用Prism时，交互请求对象比使用交互服务模式更可取。对于我来说，交互服务应该在简单的情况下使用，即当你有一个标准的消息弹出窗口，并且只有文本内容要改变的时候。另一方面，当UI更复杂时，交互请求对象更适合。但是交互服务更容易实现，并且需要的代码更少。你认为如何？

Answer 1

使用交互服务显示消息框的巨大缺点是父窗口-或者更确切地说，缺少父窗口。

从视图模型或服务实现中，您应该提供哪个窗口作为消息框的父窗口？如果您选择Application.Mainwindow，您将对整个应用程序布局做出一个巨大的假设。

流程中知道如何显示交互的唯一实体是视图。无论是使用消息框，还是页面内覆盖。

如果使用交互服务，几乎没有有效的论据支持。通常使用的一种方法是它更容易。这可能是真的，但对许多其他不应该做的事情也是如此，例如代码隐藏等。

Answer 2

我同意您的观点，即交互服务可以适用于常见的交互行为，如MessageBoxes等。

在我看来，归根结底是阶级责任。换句话说，您是否希望ViewModel或视图负责指定应该发生的交互类型？

考虑一个基本的交互服务接口：

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

通过观察界面，很明显ShowMessageBox将产生什么样的行为。这使ViewModel在指定它期望发生的交互行为类型方面具有一定程度的控制权。这种方法的问题是，您的ViewModel现在依赖于IInteractionService，并且它的交互行为预期也是明确的。这可能会降低ViewModel的可重用性。

使用Interaction对象，您可以将更多的交互行为的责任放在视图上。换句话说，您可以更改交互的行为和外观，而不会直接影响ViewModel。例如，交互请求的V1可以显示一个简单的MessageBox。交互请求的V2可以是比简单的按钮点击需要更多用户交互的更复杂的对话框。可以在不需要修改ViewModel的情况下管理这种交互行为改变。如果您有一个UI设计人员在项目中工作，他想要交换或更改绑定到交互请求的视图的行为或外观，那么这将非常有用。

如果你愿意，你可以使用这两种策略。换句话说，交互服务用于常见的交互行为，而交互对象用于更复杂的行为。

总之，交互服务更容易使用，但在我看来，交互对象可以使您的ViewModels更具可重用性。