patterns & practices: Composite WPF and Silverlight

Thanks Glen.

I'm with Bryan on this one.  I just had to do this a couple days ago, in fact, and the approach I took was to define an interface specific to the particular prompt that I needed to perform.  In my case, we have no desire for the prompt to be asynchronous, so we did it like so:

interface IPromptForContinueOfOperationXXX
{
    bool PromptForContinue(...);
}

where XXX is the specific operation I'm prompting for, and ... is any context arguments that represent context of the particular callback.  Then, I inject this interface onto my presentation model and provide the implementation in my view.  Under test, I just fake this (or mock it) to return the value I expect.

I do the "specific interface" so that the callee can decide how to visualize the prompt (and can handle remembering 'saved answers' (i.e. the user clicked the check box that says "don't ask me again") and whatever else the UI should know about that I don't care about the presentation model knowing).

The difference is in who decides the 'content' of the messagebox.  In the "IPromptForContinueOfOperationXXX", the contents of the dialog are determined by the object providing the service (with the exception of any parameters it needs to receive in order to properly display the dialog, which would be the arguments to the Show method).  In the IMessageBoxService approach, the 'content' of the message box is defined by the view model/presentation model.  I am not sure exactly where I stand on this, but currently I prefer to have the contents of the message box defined by the view, not the model.

Again, I'm not sure where the details really belong for the contents of the dialog, but I currently prefer them in the view, that way when my UI users say "I'd really rather this dialog read 'xxx' here and 'yyy' there" I can just move around the static text blocks (possibly filled by resource strings if needing localization), without having to modify the model.  Others could argue that this should be testable code (i.e. providing the 'contents' of the dialog) and thus should not be determined by the service but rather the caller.  I'm not convinced of the value of testing these sorts of things yet, so I prefer the former.

Kelly

I was looking for a solution to this problem as well. It seems that there are three aspects to this problem. The first is whether or not a specific command has the capability to be cancelled, the second is the determination of when the client/user should be prompted and the third is how to present the prompt to the client/user. Because the presentation model represents both the structural model as well as the behavioral model of the use case, it seems that the first two aspects of the problem should be completely defined by the presentation model and the third should be defined by the view (and of course the view could optionally use a centralized message box service).

With this in mind, my solution was to simply extend the ICommand interface and create an ICancelableCommand that exposes a cancel event that should be executed by the Execute method of the ICommand. By doing this any object that has a reference to the presentation model (i.e. the View) can elect to handle the cancel event and prompt however is appropriate and set the CancelEventArgs.Cancel property if necessary. This also nicely encapsulates the behavior (capability/prompt timing) within the command itself and does not couple the entire presentation model to some special IPromptForContinueOfOperationXXX interface.

public interface ICancelableCommand : ICommand
{
    event CancelEventHandler Executing;
}

public interface ISomePresentationModel
{
    ICancelableCommand CloseCommand { get; }
}

public class SomeView
{
    public ISomePresentationModel Model
    {
        get { . . . }
        set
        {    . . .
            // This of course could be bound in XAML
            value.CloseCommand.Executing += CloseCommand_Executing;
        }
    }

    void CloseCommand_Executing(object sender, CancelEventArgs e)
    {
        // Prompt and optionally set e.Cancel = true;
        // This of course could be entirely handled in XAML :)
    }
}

Doug