views:

220

answers:

3

I've been using MVVM pattern for a while now, but I still run into problems in real-life situations. Here's another one: I use commanding and bubble up the event to be handled in the ViewModel. So far, so good. But the project for which I'm using MVVM is actually a class library. Once I run the command code, I need to be able to send an object back to the calling application. What are suggested ways to do so?

Specifically: In my calling app I have a XAML page bound directly to the library's ViewModel, which contains an object "Thing1". When a button is clicked, a method in the ViewModel is called (call it "CopyThing1()"). It copies "Thing1" to create "Thing2". Then I need to send "Thing2" back to the calling app.

Thanks!!!

A: 

If Thing2 is another property on your viewmodel, you can use normal INotifyPropertyChanged to inform the UI of the change.

You could also use Prism's EventAggregator for a more decoupled approach

qntmfred
Thanks. This was my original thinking, but the response in the calling app will not solely be a UI response. So I wasn't sure how to get Thing2 creation to kick off an event to which the calling app's code-behind can respond.
ml_black
Actually, do you know of a good example of EventAggregator use? Also, what's the advantage of Prism's version over the out-of-the-box?
ml_black
OK, I get it now. Didn't realize where Prism came from. Is the QuickStart the simplest example you know of?
ml_black
Yes, the quickstart is about as simple as it gets for Prism. Though Prism has been criticized by some for being too kludgy. Several other MVVM frameworks (see http://stackoverflow.com/questions/1280462) have implementations of this pattern too.
qntmfred
+2  A: 

Commands don't return values, they change the state of your application. In case of ICommands attached to ViewModels it's pretty simple, because you can do this by simply mutating the ViewModel when the command is executed.

Using the RelayCommand from Josh Smith's excellent MVVM article:

public class MyViewModel : INotifyPropertyChanged
{
    private readonly ICommand mutateCommand;
    private Thing thing;

    public MyViewModel()
    {
        this.mutateCommand = new RelayCommand(this.Mutate);
    }

    public ICommand MutateCommand
    {
        get { return this.mutateCommand; }
    }

    public Thing Thing
    {
        get { return this.thing; }
        set
        {
            this.thing = value;
            // raise PropertyChanged event here...
        }
    }

    private void Mutate(object parameter)
    {
        this.Thing = new Thing();
    }
}

After you call myVM.MutateCommand.Execute(new object()); you can access the new value of myVM.Thing.

Mark Seemann
Thanks. I had thought of this. Actually my example wasn't the greatest. What I'm really trying to do is have one object (Thing1) to which my XAML page is bound, and then click a button on that page and have a second thing (Thing2--same structure as Thing1, but not Thing1) instantiated. So I can declare a Thing1 and a Thing2 in my ViewModel. When Thing2 is created, the bound page needs to respond in code-behind i.e. it's not simply going to be a UI-related response that's needed. Not sure how to get the code-behind to respond to this non-UI event.
ml_black
@ml_black: Don't use code-behind; use ViewModels and let the Views simply reflect that the ViewModels change. Communication goes only one way. It's a much cleaner approach.
Mark Seemann
I agree. But the calling app isn't using ViewModels. And this ViewModel is meant for more than one calling app. So in this case, the information from Thing2 has to get consumed by each calling app in its own way. The library is to be purely MVVM.
ml_black
+1  A: 

Although the info on Commanding was clear and correct, it couldn't be applied in my case because the reponse required to happen was in a calling application NOT using MVVM and it was not to be UI response only. I did investigate Prism, but found it too complex for what I need at the moment. I ended up raising and handling events, as described here--> WPF MVVM Correct Way to Fire Event on View From ViewModel

ml_black