1
votes

I'm a junior developer who recently got looking into WPF/MVVM and now after a good few months I'd say I'm a half decent WPF dev who can use the MVVM pattern well. Now I've stumbled onto Prism which drew me in because of some of the nice features it offers. However, after starting a practice application to test the Prism library I have hit some walls which were never a problem when using regular old WPF/MVVM. My main question:

What is the best way to allow communication between parent and child view models using Prism?

When I say communication, I mean allowing a parent view model such as 'Address Book VM' to access a child view model such as a 'Person VM' and all of its properties... as this is what I have been taught to do. I would have accomplished this by having a child view model property in the parent view model and then simply using a content control in the view and setting it's datacontext to the child viewmodel. From this I have a hierarchical structure where the parent can access the childs properties or the child can use a command in the parent etc.

However, when using Prism to instantiate View Models I use the ViewModelLocator - this finds the view model for us and instantiates it. Using this method there is no child property referencing the view model in the parent meaning the parent doesn't have easy access to the childs properties and vice versa. Is there an easy solution to this?

Now if anything you've read sounds fundamentally wrong concerning the use of Prism or the MVVM pattern then please inform me - I'm all ears. There's a good chance that I'm approaching everything in an incorrect way.

2
What's the scenario here? Why would you need access to child and parent properties from a parent and a child? Each one of them might have its own view, displaying those properties.mechanic

2 Answers

1
votes

What mm8 said, although I find EventAggregator to be overkill for the kind of child viewmodels that you're talking about.

In my view, you're complicating things by using a ViewModelLocator pattern which magicks away the instantiation of your viewmodels and so leaves you having to use loosely-coupled solutions like EventAggregator for everything. EventAggregator is a fantastic tool and I use it in all my projects but your use of ViewModelLocator is forcing you to use it or something like it and that's not good.

If you can reverse the causal flow of your project so that your code instantiates ViewModels and the views are provided using DataTemplates then you'll generally find that problems like this go away and you can simply instantiate your own child viewmodels and inspect child viewmodel properties in the normal way.

This question explains why ViewModelLocator was felt necessary but since it became possible to use d:DesignInstance to specify design-time DataContexts the need for it has fallen away, imho.

d:DataContext="{d:DesignInstance myNamespace:MyViewModel, IsDesignTimeCreatable=True}"

1
votes

You could use the event aggregator to communicate between two view models in a loosely coupled way. Please refer to the followigng blog post for more information about the concept:

Using the event aggregator pattern to communicate between view models: https://blog.magnusmontin.net/2014/02/28/using-the-event-aggregator-pattern-to-communicate-between-view-models/

There is a full code sample available on Prism's official GitHub site: https://github.com/PrismLibrary/Prism-Samples-Wpf/tree/master/14-UsingEventAggregator