Question

I have viewmodel1 and viewmodel2.

Viewmodel1 needs to show data from a list of some sort contained in model.
Viewmodel2 needs to input data to the list contained in model.

So both Viewmodel1 and Viewmodel2 need to “know” about model.

What is the proper way to do this in MVVM?

Should I create model in app and give viewmodel1 and viewmodel2 a reference to it or?

Answer 1

I find it helps if I think of a ViewModel as being a Model, translated just for the View.

You have a few choices:

• Create a controller which sets up the ViewModel. This is usually a good choice if the ViewModel needs information from more than one place. You can either give the ViewModel a reference to all the information it needs, or make it a Plain Old .NET Object (PONO) and have the controller set it up for you.

• Just pass the reference to the ViewModel as you suggest. Useful if no interaction is required between different classes

• Wire up the EventAggregator, which can be used to publish a notification when models change, and pass a Repository to the ViewModels so that each of them can go and get / store the model when they need to.

I really like the last pattern as it’s easily scalable if you find you need more presenters or controllers with access to these kinds of models. It also lets you inject a repository, which means you can more easily move to a nice RESTful service-oriented architecture later.

If you haven’t done much dependency injection before then please consider doing it through the constructor. This will help you avoid situations where things are trying to use your ViewModels before they’re ready, and lets the ViewModels do their own work. You might also want to look at frameworks like Unity or Castle Windsor which can help you do this kind of wiring, but that’s really only for big Enterprise projects (and not even all of them).