CODEWITHSUNDEEP
c#wpfmvvm
Casper Thule Hansen
Casper Thule Hansen

Reputation: 1550

Multiple viewmodels using 1 model?

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?

Upvotes: 2

Views: 5015

Answers (3)

Rachel
Rachel

Reputation: 132558

That's perfectly fine. Models are meant to be just what they sound like: data models. They're meant to be dummy objects that hold data, which the rest of the application can use as needed.

ViewModels are models that reflect the View. For example, suppose you had a LoginViewModel and an ManageUsersViewModel. Both ViewModels would work with the UserModel data object, however they are entirely different ViewModels for entirely different things.

In most cases, I would leave the responsibility of loading Models up to the ViewModel. For example, you normally wouldn't pre-load the Users list prior to the User logging in so you'd have their User object available. Insetad, your LoginViewModel would make it's own database call to get the User model of the user logging in, while the ManagerUsersViewModel would make its own database call to get the list of users that can be modified.

Upvotes: 3

Shoaib Shaikh
Shoaib Shaikh

Reputation: 4585

You must be thinking in a wrong way.. in MVVM your model are contained in ViewModels all the way to the views.. lets say if there is a ObservableCollection then there will be a property in you viewmodel for this and you should be initializing this collection in constructor/some method of the ViewModel.. both viewmodels will initialize ProductTypes like this.. In my opinion you should try create Classed For Model,ViewModel,Repository and use IoC in it..

here is a really good video on mvvm you should try this video and have a look at the code as well.

http://blog.lab49.com/archives/2650

If the List you mentioned is something that will never change you should try creating a singleton ViewModel for this and reference that viewmodel in other viewmodels.

Regards.

Upvotes: 0

Lunivore
Lunivore

Reputation: 17602

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).

Upvotes: 3

Related Questions