CODEWITHSUNDEEP
wpfmvvm
MrScf
MrScf

Reputation: 2497

Best practice for calling View from ViewModel in WPF

I am looking for an little example of wpf project where contains a best practice to navigate between views. Maybe with the framework MVVM Light and a NavigationService or ServiceLocator. Instead of calling View from ViewModel, how do you do that? How is your approach? Do you have a project example?

Upvotes: 0

Views: 1803

Answers (2)

kidshaw
kidshaw

Reputation: 3451

A way I favour is to have a main window with a content control. Behind that is a view model with an application state property based upon a shared enumeration.

The enumeration is intended to represent the current state but consider each to be the view you want displaying if that's easier.

Using a template selector bound to this property I control the view presented within the content control on my main window.

This approach requires you to manage a template selector with template properties for each enumeration value or view you want to be the main content. But the template only needs to include an instance of your view, so minimum XAML.

In the background, I use MVVM light to provide a Viewmodel locator data source making my views really easy to instantiate. They also use a singleton viewmodel so state is managed in between uses. I then also use the messaging framework to send messages to my main window view model telling it which state I now want. This means any viewmodel can post a message to switch to another state, without knowing what view that will be, but ultimately the main window view model manages that transition.

Apologies for lack of code examples here, this is an outline of something I have done a number of times but I don't have a clean sample to share.

This is hopefully enough to explain my approach, but feel free to comment if this doesn't make sense or fit what you're trying to do.

For dialogs... Typically I have default dialogs I reuse, but the same principle can be used. Instead of being the main window control and VM, have a secondary one for dialogs which works the same but makes itself visible as requested and closes itself once complete. Again mvvm light messenger is your friend here.

Your message includes the dialog 'state' which controls the view presented.

This would only work if your design will allow only one dialog at a time.

Finally, for tabs...

I'd look at having an observable collection of the state enumeration in the main view model. Then build the tabs by binding to that. Not something I've done but that is where I'd start. –

Upvotes: 1

Liero
Liero

Reputation: 27328

I prefer ViewModel first approach. That means navigation service take viewmodel as a parameter and then, based on naming convention, instance of view is created and loaded into frame.

navigationService.Navigate<SomePageViewModel>()

This has couple of advantages over URI based navigation, which is view first approach:

  • Better testability
  • possibility of dependency injection into view
  • most important: Better maintability. If you rename or move your pages, this will won't compile until you fix it, unlike URIs. Uri's would throw error at runtime

Unfortunelly, I can't give you mine example project right now, but it's quite easy to implement your own

Upvotes: 2

Related Questions