我想知道何时使用Prism，交互请求对象比使用交互服务模式更可取。 至于我，应该在简单的情况下使用交互服务，即当你有一个标准的消息弹出窗口，并且只会改变文本内容。另一方面，当UI更复杂时，交互请求对象更适合。但是，交互服务更容易实现，并且需要更少的代码。 你觉得怎么样？
答案 0 :(得分：2)
使用交互服务显示消息框的巨大缺点是父窗口 - 或者说缺少一个消息框。
您应该从视图模型或服务实现中提供什么窗口作为消息框的父级？如果选择Application.Mainwindow，则会对整个应用程序布局做出巨大的假设。
流程中唯一知道如何显示交互的实体是视图。无论是使用消息框还是页内覆盖。
如果使用交互服务，几乎没有有效的参数支持。经常使用的是它更容易。这可能是真的，但对于许多其他不应该做的事情也是如此，例如：代码背后等等。
答案 1 :(得分：1)
我同意您的意见，交互服务可以适用于常见的交互行为，例如MessageBoxes等。
在我看来，它归结为阶级责任。换句话说，您是否希望ViewModel或View负责指定应该进行的交互类型？
考虑基本的交互服务界面：
public interface IInteractionService{
MessageBoxResult ShowMessageBox(string messageBoxText, string caption, MessageBoxButton button);
}
通过观察界面ShowMessageBox将产生什么类型的行为，这是相当明显的。这为ViewModel提供了一定程度的控制，以指定它预期发生的交互行为的类型。这种方法的问题是你的ViewModel现在依赖于IInteractionService以及明确它的交互行为期望。这可能会降低ViewModel的可重用性。
使用交互对象，您可以在视图上承担更多交互行为的责任。换句话说，您可以更改交互的行为和外观，而不会直接影响ViewModel。例如，交互请求的V1可以显示简单的MessageBox。交互请求的V2可以是更复杂的对话，需要更多的用户交互，只需点击一下按钮。可以在不需要修改ViewModel的情况下管理这种交互行为更改。如果您有一个处理项目的UI设计人员希望选择换出或更改与交互请求相关联的视图的行为或外观，那么这将非常有用。
如果您愿意，可以使用这两种策略。换句话说，用于常见交互行为的交互服务和用于更复杂行为的交互对象。
总而言之，交互服务可以更容易使用，但在我看来，交互对象可以使您的ViewModel更具可重用性。