What is best practice for sharing model objects between multiple viewmodels?

Question

In my WPF application I'm using the MVVM pattern and the repository pattern. I have a repository that provides a list of aircraft objects. From a user perspective, I want to display these aircrafts in several different ways (e.g. on a map, in lists, in textual form, etc..), and also allow the user to filter the objects. To achieve this I have built views and viewmodels for each of the different ways of representing the data.

My problem now is that I'm not sure what the best practice is for making the list of aircraft objects available for all the different viewmodels. Here's some of the alternatives I've considered:

1.Inject the repository into each viewmodel, and then get all the objects from the repo.

2.Inject the repository into a MainViewModel that retrieves all the objects from the repo, and then inject the object collection into all other viewmodels that needs it.

So in sum: I have a set of viewmodels that all make use of the same collection of model objects. What is the best practice for sharing this collection between the viewmodels when using the repository pattern?

Answer 1

In a WPF application I'll typically create service objects which encapsulate repositories which in turn contain a session object each, but I use dependency injection to inject the actual implementations. One of the major benefits of doing this is that everything can be easily mocked for unit testing, but another one is that you now have total control over the scope of these objects. If you're pulling your data from a database then you'll have different strategies for session management depending on whether you're developing a windows app vs a web site (say) and in enterprise applications this requirement will change even within the same code base. There's a good article on Germán Schuager's blog discussing the pros and cons of various session management strategies but for WPF applications using one session per form seems to be a good one. If you're using something like Ninject then you simply scope your ISession object to the view model for your top-level "page" and then all the objects within the logical hierarchy for that page can create their own repositories without needing to know about each other. Since they're all sharing the same session object they're also sharing the same entities in the repository cache and thus the model is now being shared by multiple view models. The only thing that remains is to add property notification to the entity classes in your domain layer so that changes made by one view model propagate through to the others, but that's a topic for another post (hint: your DB layer should provide some mechanism for injecting your own wrapper proxies to add property change notification automatically using things like Castle DynamicProxy etc).

Answer 2

Your data should be located in some place... (Service, Database, File, Etc...). In that case, you should have a class which manage yours client requests: GetAllAircrafts, Create, Update, Etc... This class somtimes called XXXService. I think that this is where you should expose your collection of models. This service can be injected to the view models and share the collection of models through a get property (Maybe as a read only collection...?)

Good luck !

Answer 3

We have a complex composite financial application where we needed to share various model objects across viewmodels, So we took an approach: we created a high level Model Object which holds collections of other model entities. This high level model is returned/populated in servicelayer. We share this high level model object in many viewmodels and with many PRISM modules using event aggregator .

So in your case you may have a AircarftsData Model, which can maintain collection of aircrafts. you can populate this model using your repository. Then You can pass this AircarftsData in various viewmodels.

We have shipped our application in production with this design and faced no issues as such. One thing you might want to be careful of Memory leakage of this Model object. If somehow any child object of this Model is leaked in memory then whole high level model may remain in memory.

Answer 4

The general rule of thumb is that EACH view should have it's own ViewModel, you can reuse ViewModels via inheritance or adding properties but again a view "DESERVES" it's own ViewModel.

You can have your views leverage interfaces, your viewmodels can implement interfaces.