Interaction request interaction service

Question

I would like to know when Prism is used, interaction request objects are preferable to use the interaction service template. For me, Interaction Service should be used in simple cases, that is, when you have a standard pop-up message, and only the text content will be changed. Interaction request objects, on the other hand, are more suitable when the user interface is more complex. But the Interaction Service is much easier to implement and requires less code. What do you think?

Answer 1

A huge disadvantage of using the interaction service to display a message box is the parent window — or rather, the absence of one.

In which window should you specify the parent of the message window, from the presentation model or service implementation? If you choose Application.Mainwindow, you will make a huge assumption about the general layout of the application.

The only object in the process that knows how to display interaction is presentation. Regardless of whether you use this message box or overlay on the page.

There are several valid arguments for using the interaction service. Often used is that it is easier. This may be true, but it also applies to many other things that should not be done, for example. code behind etc.

Answer 2

I agree with you that the interaction service may be suitable for normal interaction behavior such as MessageBoxes, etc.

In my opinion, it comes down to class responsibility. In other words, do you want the ViewModel or View to be responsible for determining what type of interaction should take place?

Consider the basic interface of the interaction service:

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

From observing the interface, you can see what type of behavior ShowMessageBox will produce. This gives the ViewModel some degree of control in terms of determining what type of interaction behavior it expects. The problem with this approach is that your ViewModel now has a dependency on IInteractionService, and is also an explicit expectation of interaction behavior in it. This may make your ViewModel less reusable.

Using interaction objects, you can place greater responsibility for the interaction behavior on a view. In other words, you can change the behavior and appearance of the interaction without directly affecting the ViewModel. For example, an interaction request V1 may display a simple MessageBox. Interaction request v2 can be a more complex dialogue requiring more user interaction with a simple click of a button. This change in interaction behavior can be controlled without the need to modify the ViewModel. This can be useful if you have a user interface designer working on a project who wants to change or change the behavior or appearance of the view associated with the interaction request.

You can use both strategies if you want. In other words, an interaction service for general interaction behavior and interaction objects for more complex behavior.

To summarize, interaction services may be easier to use, but interaction objects can make your ViewModels more reusable, in my opinion.